"Невезучий год"
В большей или меньшей мере, но все люди обращают внимание на ощущение "везения" или "невезения". Кто-то всерьёз считает свою везучесть или невезучесть важным личным свойством, кто-то отмечает лишь мимоходом; кто-то списывает на случайность, кто-то всерьёз заранее готовится.
Но этот год примечателен тем, что всему человечеству "не повезло". Примечательно здесь то, что, в противовес конкретным материальным потерям, которые перенесла пусть значительная, но всё же часть человечества, это иррациональное ощущение "невезения" воздействует на всех – даже на тех, кто объективно не проиграл (а может и немного выиграл) в сложившихся обстоятельствах.
Что, конечно, является иллюстрацией феномена "коллективности" человеческого сознания. Душа болит за человечество! :)
#psychology
В большей или меньшей мере, но все люди обращают внимание на ощущение "везения" или "невезения". Кто-то всерьёз считает свою везучесть или невезучесть важным личным свойством, кто-то отмечает лишь мимоходом; кто-то списывает на случайность, кто-то всерьёз заранее готовится.
Но этот год примечателен тем, что всему человечеству "не повезло". Примечательно здесь то, что, в противовес конкретным материальным потерям, которые перенесла пусть значительная, но всё же часть человечества, это иррациональное ощущение "невезения" воздействует на всех – даже на тех, кто объективно не проиграл (а может и немного выиграл) в сложившихся обстоятельствах.
Что, конечно, является иллюстрацией феномена "коллективности" человеческого сознания. Душа болит за человечество! :)
#psychology
Рецепт успешного миллиардного бизнеса
Как сделать бизнес, который очень быстро захватит национальный (а следом и международный) рынок? Рецепт очень простой и хорошо воспроизводимый.
Допустим, мы хотим стать самым популярным производителем шаурмы. Для этого нам надо, всего лишь, не брать 150 рублей с клиентов, а доплачивать каждому, для начала, 50 рублей. Если появится конкурент с похожей бизнес-моделью, то стоит начать доплачивать 100 рублей.
Стоит отметить, что, при каждущейся абсурдности, подобной бизнес-модели следует уже который год Uber, AirBnB, Tesla, и т. д.
В целом можно рассматривать такой расклад с двух точек зрения, при которых подобная стратегия обретает смысл:
1. Раздаются не свои деньги. Конкретно, раздаются деньги инвесторов, привлечённых в момент очередной эмиссии акций, которые привлекаются под обещания дальнейшего роста стоимости акций, за счёт привлечения новых инвесторов, и т. п.
2. Владельцы организации получают выгоду не от этой организации (то есть рассматриваемая организация, по сути, является некоммерческой – кстати, иногда декларация "нам деньги не нужны" прямо в таком виде звучит из уст мажоритарного акционера или высшего руководства компании). Например, владельцы считают убытки терпимыми на фоне получаемого доступа к персональной информации и т. п.
Здесь хотел отметить, что покупку акций подобных компаний не стоит для самого себя обозначать словами "инвестиции" или "вложение в бизнес", или ещё чем-то вроде того. Бизнеса (то есть прибыльного дела) потому что в такой схеме нет (точнее будет сказать, он есть, но не соответствует формально обозначаемой деятельности). На таких акциях можно "заработать", но нельзя "зарабатывать на пенсию".
Впрочем, как всегда, это не инвестиционная рекомендация, а автор не является профессиональным инвестором.
#investing
Как сделать бизнес, который очень быстро захватит национальный (а следом и международный) рынок? Рецепт очень простой и хорошо воспроизводимый.
Допустим, мы хотим стать самым популярным производителем шаурмы. Для этого нам надо, всего лишь, не брать 150 рублей с клиентов, а доплачивать каждому, для начала, 50 рублей. Если появится конкурент с похожей бизнес-моделью, то стоит начать доплачивать 100 рублей.
Стоит отметить, что, при каждущейся абсурдности, подобной бизнес-модели следует уже который год Uber, AirBnB, Tesla, и т. д.
В целом можно рассматривать такой расклад с двух точек зрения, при которых подобная стратегия обретает смысл:
1. Раздаются не свои деньги. Конкретно, раздаются деньги инвесторов, привлечённых в момент очередной эмиссии акций, которые привлекаются под обещания дальнейшего роста стоимости акций, за счёт привлечения новых инвесторов, и т. п.
2. Владельцы организации получают выгоду не от этой организации (то есть рассматриваемая организация, по сути, является некоммерческой – кстати, иногда декларация "нам деньги не нужны" прямо в таком виде звучит из уст мажоритарного акционера или высшего руководства компании). Например, владельцы считают убытки терпимыми на фоне получаемого доступа к персональной информации и т. п.
Здесь хотел отметить, что покупку акций подобных компаний не стоит для самого себя обозначать словами "инвестиции" или "вложение в бизнес", или ещё чем-то вроде того. Бизнеса (то есть прибыльного дела) потому что в такой схеме нет (точнее будет сказать, он есть, но не соответствует формально обозначаемой деятельности). На таких акциях можно "заработать", но нельзя "зарабатывать на пенсию".
Впрочем, как всегда, это не инвестиционная рекомендация, а автор не является профессиональным инвестором.
#investing
Поздравляю с Новым годом!
Моё открытие года в том, что python ничем не отличается от ruby. Казалось бы, хоть какие-то минимальные отличия должны быть, но по факту вообще никаких.
Конечно, кроме того факта, что ruby в большей мере соответствует знаменитому дзену python.
#programming
Моё открытие года в том, что python ничем не отличается от ruby. Казалось бы, хоть какие-то минимальные отличия должны быть, но по факту вообще никаких.
Конечно, кроме того факта, что ruby в большей мере соответствует знаменитому дзену python.
#programming
Хроники смерти Ruby: первоисточник (1/6)
Сейчас можно считать сложившимся мнением среди настоящих софтверных инженеров, привыкших получать информацию из третьих рук и доверять экспертному мнению профессиональных IT-журналистов, что Ruby умирает (вариант: уже умер).
Интересно проследить историческую перспективу развития вопроса.
Впервые поднял тему, взявши сразу быка за рога, некий Jeff Cogswell в статье от 2014 года с недвусмысленным названием "5 языков программирования, назначенных умереть" ("5 Programming Languages Marked for Death").
Раздел про Ruby начинается с предложения, пытающегося подчеркнуть для читателей, насколько автор в теме: "всего десять лет назад, Руби был на пике моды [по Руби все сходили с ума]". Напомню, десять лет назад от момента написания статьи был 2004 год. Два года до выхода первой версии Ruby on Rails. Ruby вообще никто не знал, это был хоббийный проект нескольких неизвестных японских разработчиков из академических кругов.
Но всё же за что Джефф приговорил Ruby?
Утверждает, что, мол, "мы, люди, которые выросли на С-подобном синтаксисе, путаемся и спотыкаемся при изучении того, как работает Ruby". Дальше приводит два примера, в чём профессиональные С-программисты путаются: "hello, world" и функция для вычисления факториала:
Дальше в статье приводится типовой аргумент "про Твиттер": "все любят язык, а вот Твиттер переписал весь проект с Ruby, т.к. не хватило производительности".
Для динамического языка, вообще говоря, нет ничего позорного в эволюции проекта вида "быстро написали, потом переписали на статическом языке". Это нормальное и даже целевое применение технологии. Благодаря этому Твиттер смог получить первых пользователей и, не застряв в болоте Java-разработки, заработать денег на дальнейшее развитие. Закономерный ход типовой эволюции стартапа. Но примечательно здесь то, что второго примера, кроме Твиттера, такой эволюции для Ruby никогда не приводят. Проектов на Rails сколько угодно любых размеров, а вот примеров отказа от технологии единицы. То есть в плане производительности Ruby/Rails всех, по большому счёту, устраивает.
Итак, Джефф пишет, с лёгкой иронией и играя словами, что в 2011 году Ruby уже, в мыслях автора, умер. В тот же год в реальном мире разработчик языка, Юкихиро Матсумото, был принят на руководящую техническую позицию в Heroku, недавно закрывшего сделку по продаже компании (2010) за $200 млн.
Heroku начал свой путь как система развёртывания и хостинга Ruby-приложений. Так сказать, от Ruby-разработчиков для Ruby-разработчиков. И так лихо сделал и реализовал ставку на умирающий язык, что за три года из "гаражного стартапа" превратился в одного из лидеров начавшейся индустрии "контейнерных-облачных хостингов".
В то время крупнейшие компании практически одновременно начали "гонку вооружений" за раздел только начавшего появляться (но уже заранее понятно, что сулящего огромные прибыли) рынка "цифровых облаков". Amazon запускает AWS (2006); Google – Cloud Platform (2008); Microsoft, спохватившись позднее всех, Azure (2010). В разгар битвы слона, кита и бегемота без лишнего шума и пыли откусывает значительную часть пирога Heroku (2007-2010), который практически сразу выкупает разработчик CRM-систем Salesforce (2010). Актив не совсем профильный, но Salesforce верно рассчитала, что дело того стоит, да и цена сделки, в масштабе разворачивающихся событий, копеечная. Благодаря своей прозорливости Salesforce до сих пор борется с "облачными конкурентами" более чем на равных. Heroku остаётся обособленным подразделением, продолжающим развивать платформу под крылом материнской компании.
#programming #ruby
Сейчас можно считать сложившимся мнением среди настоящих софтверных инженеров, привыкших получать информацию из третьих рук и доверять экспертному мнению профессиональных IT-журналистов, что Ruby умирает (вариант: уже умер).
Интересно проследить историческую перспективу развития вопроса.
Впервые поднял тему, взявши сразу быка за рога, некий Jeff Cogswell в статье от 2014 года с недвусмысленным названием "5 языков программирования, назначенных умереть" ("5 Programming Languages Marked for Death").
Раздел про Ruby начинается с предложения, пытающегося подчеркнуть для читателей, насколько автор в теме: "всего десять лет назад, Руби был на пике моды [по Руби все сходили с ума]". Напомню, десять лет назад от момента написания статьи был 2004 год. Два года до выхода первой версии Ruby on Rails. Ruby вообще никто не знал, это был хоббийный проект нескольких неизвестных японских разработчиков из академических кругов.
Но всё же за что Джефф приговорил Ruby?
Утверждает, что, мол, "мы, люди, которые выросли на С-подобном синтаксисе, путаемся и спотыкаемся при изучении того, как работает Ruby". Дальше приводит два примера, в чём профессиональные С-программисты путаются: "hello, world" и функция для вычисления факториала:
puts 'Bye bye, Miss American Ruby! Drove my Chevy to the Levie…'Текст примеров понятен даже человеку, который вообще не умеет программировать.
puts '2011 was the day that Ruby died, yeah…'
def fact(n)
if n == 0
1
else
n * fact(n-1)
end
end
puts fact(ARGV[0].to_i)
Дальше в статье приводится типовой аргумент "про Твиттер": "все любят язык, а вот Твиттер переписал весь проект с Ruby, т.к. не хватило производительности".
Для динамического языка, вообще говоря, нет ничего позорного в эволюции проекта вида "быстро написали, потом переписали на статическом языке". Это нормальное и даже целевое применение технологии. Благодаря этому Твиттер смог получить первых пользователей и, не застряв в болоте Java-разработки, заработать денег на дальнейшее развитие. Закономерный ход типовой эволюции стартапа. Но примечательно здесь то, что второго примера, кроме Твиттера, такой эволюции для Ruby никогда не приводят. Проектов на Rails сколько угодно любых размеров, а вот примеров отказа от технологии единицы. То есть в плане производительности Ruby/Rails всех, по большому счёту, устраивает.
Итак, Джефф пишет, с лёгкой иронией и играя словами, что в 2011 году Ruby уже, в мыслях автора, умер. В тот же год в реальном мире разработчик языка, Юкихиро Матсумото, был принят на руководящую техническую позицию в Heroku, недавно закрывшего сделку по продаже компании (2010) за $200 млн.
Heroku начал свой путь как система развёртывания и хостинга Ruby-приложений. Так сказать, от Ruby-разработчиков для Ruby-разработчиков. И так лихо сделал и реализовал ставку на умирающий язык, что за три года из "гаражного стартапа" превратился в одного из лидеров начавшейся индустрии "контейнерных-облачных хостингов".
В то время крупнейшие компании практически одновременно начали "гонку вооружений" за раздел только начавшего появляться (но уже заранее понятно, что сулящего огромные прибыли) рынка "цифровых облаков". Amazon запускает AWS (2006); Google – Cloud Platform (2008); Microsoft, спохватившись позднее всех, Azure (2010). В разгар битвы слона, кита и бегемота без лишнего шума и пыли откусывает значительную часть пирога Heroku (2007-2010), который практически сразу выкупает разработчик CRM-систем Salesforce (2010). Актив не совсем профильный, но Salesforce верно рассчитала, что дело того стоит, да и цена сделки, в масштабе разворачивающихся событий, копеечная. Благодаря своей прозорливости Salesforce до сих пор борется с "облачными конкурентами" более чем на равных. Heroku остаётся обособленным подразделением, продолжающим развивать платформу под крылом материнской компании.
#programming #ruby
Ну а Джефф к моменту написания статьи уже сильно отошёл от программирования ("разработку на jQuery" за программирование считать не будем). Зато всерьёз занялся набравшим популярность devops-ом. На наборе технологий прямого конкурента Heroku – AWS. Через год после написания статьи его собственный бизнес на данную хайповую тему "не пошёл" и был "приостановлен на неопределённое время", но, к счастью, ниша для "консультанта по облакам" с опытом С++ и без понимания потребностей стартапов находится. Джефф в конечном итоге оседает "AWS-консультантом" в крошечном провинциальном провайдере услуг телефонии и интернета. Что ж, дело полезное: как минимум, кто-то должен объяснять, в чём именно польза от освоения средств на "облачную инфраструктуру" (для телефонной компании).
Инженер, списавший Ruby в устаревшие языки, был списан как устаревший программист и бизнесмен. Диалектика.
#programming #ruby
Инженер, списавший Ruby в устаревшие языки, был списан как устаревший программист и бизнесмен. Диалектика.
#programming #ruby
Хроники смерти Ruby: круги на воде (2/6)
Посредественная статья от "учителя, автора книг, С++-разработчика, AWS-консультанта" (см. прыдудщие посты), опубликованная в довольно крупном онлайн-издании, породила круги на воде. Люди начали задавать вопросы, ставить промблемы.
"Рубисты", конечно, в основном продолжали заниматься своим делом и вообще были не в курсе происходящего. Я сам в 2014 взялся за очередной проект, стейкхолдеры которого (не будучи программистами) выбрали Rails за его рентабельность для бизнеса. И так, как-то по инерции, переходя раз в год-два на очередной новый проект с очередным рутинным повышением зарплаты, узнал о том, что Ruby умер, году в 2019-м. Узнал случайно, поскольку тема начала подниматься в кругах потенциальных клиентов Rails-курса, где я преподаю.
В инфополе, тем временем, в 2014-2015 году кто-то лениво отпинывался от статьи Джеффа, мягко намекая, что ставить в один ряд Perl, Delphi, VB.NET и Ruby это несколько перебор, в независимости от популярности последнего.
Кто-то закинул удочку прямо в мейлинг лист по Ruby, в обсуждение довольно мелкого, но всё же существенного рутинного технического вопроса (введения frozen string literals по умолчанию): один из разработчиков риторически спросил, не умирает ли Ruby потому, что другой разработчик настаивал на изменениях(!) языка в сторону упрощения(!) его применения конечными пользователями. Логика абсурдная, но вброс был сделан. "Внутренний круг разработчиков Ruby обсуждает, не умирает ли Ruby".
Кто-то начал использовать заданный тренд демагогии для оправдания недостатков конкурирующих платформ. Очередной PHP-разработчик пишет, что "преимущества Ruby пропали с появлением Laravel". Оцените накал пафоса: Laravel – это попытка прямо скопировать успех Rails на PHP. Попытка, в определённой степени, удачная, поскольку за PHP стоят бюджеты инертного Facebook-а, в своё время прогадавшего с выбором языка, да так и тянущего за собой грузило – бюджеты, гарантирующие определённую популярность. Проблема такой попытки в следующем: разработчик Ruby старался сделать язык, удобный для людей; а разработчик PHP слепил (по собственному его признанию) тяп-ляп, и когда ему указывают на большое количество накопившихся недоработок, то он с раздражением отвечает, что исправлять ничего не собирается, всё и так хорошо, поскольку язык вон видите какой популярный. Необразованный плагиатор и имитатор через губу бросил оригинальному автору замечание о том, что у последнего "уже нет преимуществ".
Адепты серверной разработки на Javascript (появление node.js во многом воспринималась как первоапрельская шутка, сделанная в неправильное время года – но ничего, сейчас попривыкли уже) зашли с другой стороны. Пользуясь своим профессиональным опытом, они сделали следующее предсказание: т.к. веб-фреймворки постоянно рождаются и умирают, то и Rails скоро умрёт. Проблема в том, что предсказание актуально для мира Javascript, но не для Rails.
Между Rails 3-й версии (2010) и 6-й (2019) различий в базовой функциональности так мало (с точки зрения пользователя – "внутренности" минимум дважды, конечно, переписали практически полностью), что переучиться можно, наверное, за пару дней (хотя, конечно, кое-что добавили, что придётся изучать дополнительно). В тот же временной период в JS изменился сам язык до почти полной неузнаваемости, а изменения первой цифры версий фреймворков (Angular 1 -> 2, React 3 -> 17 и др.) сопровождается, фактически, полным пересмотром всех основ – по сути созданием нового фреймворка. Тот критик несколько раз за прошедшее время становился полностью неактуальными и должен был начинать, фактически, с нуля (если смог).
Rails, напротив, это очень стабильная работа. Которая будет актуальна столько времени, сколько будет актуален современный интернет (пока все не перейдут, например, в VR, или не осядут по крупнейшим соцсетям с закрытием всех независимых сайтов).
#programming #ruby
Посредественная статья от "учителя, автора книг, С++-разработчика, AWS-консультанта" (см. прыдудщие посты), опубликованная в довольно крупном онлайн-издании, породила круги на воде. Люди начали задавать вопросы, ставить промблемы.
"Рубисты", конечно, в основном продолжали заниматься своим делом и вообще были не в курсе происходящего. Я сам в 2014 взялся за очередной проект, стейкхолдеры которого (не будучи программистами) выбрали Rails за его рентабельность для бизнеса. И так, как-то по инерции, переходя раз в год-два на очередной новый проект с очередным рутинным повышением зарплаты, узнал о том, что Ruby умер, году в 2019-м. Узнал случайно, поскольку тема начала подниматься в кругах потенциальных клиентов Rails-курса, где я преподаю.
В инфополе, тем временем, в 2014-2015 году кто-то лениво отпинывался от статьи Джеффа, мягко намекая, что ставить в один ряд Perl, Delphi, VB.NET и Ruby это несколько перебор, в независимости от популярности последнего.
Кто-то закинул удочку прямо в мейлинг лист по Ruby, в обсуждение довольно мелкого, но всё же существенного рутинного технического вопроса (введения frozen string literals по умолчанию): один из разработчиков риторически спросил, не умирает ли Ruby потому, что другой разработчик настаивал на изменениях(!) языка в сторону упрощения(!) его применения конечными пользователями. Логика абсурдная, но вброс был сделан. "Внутренний круг разработчиков Ruby обсуждает, не умирает ли Ruby".
Кто-то начал использовать заданный тренд демагогии для оправдания недостатков конкурирующих платформ. Очередной PHP-разработчик пишет, что "преимущества Ruby пропали с появлением Laravel". Оцените накал пафоса: Laravel – это попытка прямо скопировать успех Rails на PHP. Попытка, в определённой степени, удачная, поскольку за PHP стоят бюджеты инертного Facebook-а, в своё время прогадавшего с выбором языка, да так и тянущего за собой грузило – бюджеты, гарантирующие определённую популярность. Проблема такой попытки в следующем: разработчик Ruby старался сделать язык, удобный для людей; а разработчик PHP слепил (по собственному его признанию) тяп-ляп, и когда ему указывают на большое количество накопившихся недоработок, то он с раздражением отвечает, что исправлять ничего не собирается, всё и так хорошо, поскольку язык вон видите какой популярный. Необразованный плагиатор и имитатор через губу бросил оригинальному автору замечание о том, что у последнего "уже нет преимуществ".
Адепты серверной разработки на Javascript (появление node.js во многом воспринималась как первоапрельская шутка, сделанная в неправильное время года – но ничего, сейчас попривыкли уже) зашли с другой стороны. Пользуясь своим профессиональным опытом, они сделали следующее предсказание: т.к. веб-фреймворки постоянно рождаются и умирают, то и Rails скоро умрёт. Проблема в том, что предсказание актуально для мира Javascript, но не для Rails.
Между Rails 3-й версии (2010) и 6-й (2019) различий в базовой функциональности так мало (с точки зрения пользователя – "внутренности" минимум дважды, конечно, переписали практически полностью), что переучиться можно, наверное, за пару дней (хотя, конечно, кое-что добавили, что придётся изучать дополнительно). В тот же временной период в JS изменился сам язык до почти полной неузнаваемости, а изменения первой цифры версий фреймворков (Angular 1 -> 2, React 3 -> 17 и др.) сопровождается, фактически, полным пересмотром всех основ – по сути созданием нового фреймворка. Тот критик несколько раз за прошедшее время становился полностью неактуальными и должен был начинать, фактически, с нуля (если смог).
Rails, напротив, это очень стабильная работа. Которая будет актуальна столько времени, сколько будет актуален современный интернет (пока все не перейдут, например, в VR, или не осядут по крупнейшим соцсетям с закрытием всех независимых сайтов).
#programming #ruby
Хроники смерти Ruby: старички на марше (3/6)
Переходим к 2016-2017 годам.
Очередной "консультант по облакам", рекламирующий себя на Quora как (не преувеличиваю, реально, так и пишет в своём профиле) "Задаватель Тяжёлых Вопросов" (ну, то есть, человек ставит промблемы-с), растекается мыслью по древу в 2016 году: Ruby плохой язык, так как обслуживает нужды Rails, а больше нигде и не используется.
Ну, во-первых, используется ещё в Devops.
Во-вторых, уважаемый, вы тему не меняйте. Речь шла про веб-разработку. С другими нишами компетентные люди разберутся, если будет время и деньги: не будите лихо. С этой уже разобрались так, что до сих пор все успокоиться не могут, так и норовят всё метку смерти налепить. Со всех сторон уже облепили, а языку хоть бы хны.
По пунктам отвечать на очередное сравнение Ruby с VB и COBOL (последний разработан в 1959 году, ещё до Алгола, положившего начало всем современным процедурным языкам, и сейчас применяется в устаревшем на полвека софте американских банков), впрочем, не буду. Мне кажется, аватар очередного эксперта по веб-разработке говорит сам за себя: то есть понятно, что человек может порассуждать предметно о COBOL-е, но вот сам факт, что он его вспомнил и привёл в аргументе, уже является в полной мере самораскрывающим. "Дедушке пора на пенсию, заговаривается".
Ну а дальше пошла плясать губерния. Основной тон плясок примерно такой:
2014 – "Ruby умер"
2016 – "Ruby умирает и вот-вот умрёт"
2019 – "Ruby ещё держится, но вот-вот начнёт умирать"
К пляскам присоединились самые широкие массы трудящихся.
Евангелисты Go (языка, который разработала и поддерживает Google, крупнейшая IT-корпорация Земли) не посчитали выше своего достоинства присоединиться к общей демагогии. Мол, "руби умер, го писать на го". Предлагается писать на сравнительно неплохой вариации на тему языка Pascal (разработан в 1970), в которой разработчикам не удалось (в основном по организационно-политическим, а не техническим причинам) заимствовать многие полезные фичи из последователя паскаля, языка Oberon (разработан в 1986).
В чём замысел Go? Go – это язык, созданный стариками для студентов. Причём стариками, которые, в сущности, не любят студентов; мало того что не понимают их (это не грех, если разница в возрасте большая), но и не хотят понять; считают их чрезмерно амбиционзными дураками, которых надо приземлить. А Ruby – это язык, созданный взрослыми людьми для взрослых людей, чтобы дать им свободу и работающий инструмент самовыражения.
Не трудно заметить, что для того, чтобы полюбить Go-разработку (по принуждению и за хорошие деньги можно писать на чём угодно), мало быть студентом, надо ещё иметь низкую самооценку.
К пляскам на короткое время присоединяются сторонники Swift. Языка, разработанного в Apple для того, чтобы дать альтернативу к тому моменту уже совсем позорной неэстетичности Objective C. В сущности, Apple, выражаясь просторечно, прокинула пользователей Ruby. Малоизвестный факт: в Apple разрабатывалась, до какого-то момента, своя версия интерпретатора Ruby (MacRuby – 2007-2012), с компиляцией в низкоуровневый байткод LLVM, за счёт чего достагалсь производительность, сравнимая с компилируемыми языками. В конечном итоге Apple решила, в своей манере, не поддерживать общественный проект, а сделать свой уникальный продукт, выпустив Swift. Впрочем, macOS/iOS разработка это свой собственный мир, с веб-разработкой практически не пересекающийся, поэтому в данном разборе уделять ему внимания больше не будем. Реинкарнация идеи "компилируемого Ruby для маков" живёт в виде проекта Rubymotion, который пока только пытается нащупать целевую нишу.
Наконец, набирает популярность язык Elixir (2012). Язык создан "рубистом" (действующим членом команды разработки Rails) Хосе Валимом для платформы Erlang. Erlang (появился в 1980-х) – платформа для "старичков", занимающихся разработкой софта для телефонных сетей и коммутаторов, получает второе дыхание и выходит на оперативные просторы, становясь не просто "надёжной" или "зарекомендовавшей себя" технологией, а модной и приятной.
#programming #ruby
Переходим к 2016-2017 годам.
Очередной "консультант по облакам", рекламирующий себя на Quora как (не преувеличиваю, реально, так и пишет в своём профиле) "Задаватель Тяжёлых Вопросов" (ну, то есть, человек ставит промблемы-с), растекается мыслью по древу в 2016 году: Ruby плохой язык, так как обслуживает нужды Rails, а больше нигде и не используется.
Ну, во-первых, используется ещё в Devops.
Во-вторых, уважаемый, вы тему не меняйте. Речь шла про веб-разработку. С другими нишами компетентные люди разберутся, если будет время и деньги: не будите лихо. С этой уже разобрались так, что до сих пор все успокоиться не могут, так и норовят всё метку смерти налепить. Со всех сторон уже облепили, а языку хоть бы хны.
По пунктам отвечать на очередное сравнение Ruby с VB и COBOL (последний разработан в 1959 году, ещё до Алгола, положившего начало всем современным процедурным языкам, и сейчас применяется в устаревшем на полвека софте американских банков), впрочем, не буду. Мне кажется, аватар очередного эксперта по веб-разработке говорит сам за себя: то есть понятно, что человек может порассуждать предметно о COBOL-е, но вот сам факт, что он его вспомнил и привёл в аргументе, уже является в полной мере самораскрывающим. "Дедушке пора на пенсию, заговаривается".
Ну а дальше пошла плясать губерния. Основной тон плясок примерно такой:
2014 – "Ruby умер"
2016 – "Ruby умирает и вот-вот умрёт"
2019 – "Ruby ещё держится, но вот-вот начнёт умирать"
К пляскам присоединились самые широкие массы трудящихся.
Евангелисты Go (языка, который разработала и поддерживает Google, крупнейшая IT-корпорация Земли) не посчитали выше своего достоинства присоединиться к общей демагогии. Мол, "руби умер, го писать на го". Предлагается писать на сравнительно неплохой вариации на тему языка Pascal (разработан в 1970), в которой разработчикам не удалось (в основном по организационно-политическим, а не техническим причинам) заимствовать многие полезные фичи из последователя паскаля, языка Oberon (разработан в 1986).
В чём замысел Go? Go – это язык, созданный стариками для студентов. Причём стариками, которые, в сущности, не любят студентов; мало того что не понимают их (это не грех, если разница в возрасте большая), но и не хотят понять; считают их чрезмерно амбиционзными дураками, которых надо приземлить. А Ruby – это язык, созданный взрослыми людьми для взрослых людей, чтобы дать им свободу и работающий инструмент самовыражения.
Не трудно заметить, что для того, чтобы полюбить Go-разработку (по принуждению и за хорошие деньги можно писать на чём угодно), мало быть студентом, надо ещё иметь низкую самооценку.
К пляскам на короткое время присоединяются сторонники Swift. Языка, разработанного в Apple для того, чтобы дать альтернативу к тому моменту уже совсем позорной неэстетичности Objective C. В сущности, Apple, выражаясь просторечно, прокинула пользователей Ruby. Малоизвестный факт: в Apple разрабатывалась, до какого-то момента, своя версия интерпретатора Ruby (MacRuby – 2007-2012), с компиляцией в низкоуровневый байткод LLVM, за счёт чего достагалсь производительность, сравнимая с компилируемыми языками. В конечном итоге Apple решила, в своей манере, не поддерживать общественный проект, а сделать свой уникальный продукт, выпустив Swift. Впрочем, macOS/iOS разработка это свой собственный мир, с веб-разработкой практически не пересекающийся, поэтому в данном разборе уделять ему внимания больше не будем. Реинкарнация идеи "компилируемого Ruby для маков" живёт в виде проекта Rubymotion, который пока только пытается нащупать целевую нишу.
Наконец, набирает популярность язык Elixir (2012). Язык создан "рубистом" (действующим членом команды разработки Rails) Хосе Валимом для платформы Erlang. Erlang (появился в 1980-х) – платформа для "старичков", занимающихся разработкой софта для телефонных сетей и коммутаторов, получает второе дыхание и выходит на оперативные просторы, становясь не просто "надёжной" или "зарекомендовавшей себя" технологией, а модной и приятной.
#programming #ruby
Хроники смерти Ruby: Ruby и Elixir (4/6)
Elixir, оттолкнувшись от рубишной базы энтузиастов и заимствовав некоторые элементы внешней эстетики языка Ruby, быстро уходит в свободное плавание. Социально активные рубисты, до которых спустя несколько лет наконец начали доходить слухи о скоропостижной кончине любимого языка, начинают давать восторженные отзывы Elixir-у. Пишутся статьи, переходят разработчики, выступают на Ruby-конференциях с обзором новой модной темы. Через пару лет возвращаются обратно на Ruby.
Elixir и Phoenix занимают свою, пока что ещё не до конца устоявшуюся, нишу в мире веб-разработки. Rails – это "через пять лет вырастем до 100 тыс. пользователей". Elixir – это "уже сейчас 1 млн. запросов в секунду". Это мир Discord-а, Whatsapp-а, некоторых подсистем серверов онлайн-игр и прочих распределённых приложений. Ниша пересекается с классическими веб-приложениями, но не сильно.
Мир Elixir, по ряду причин, очень конгруентен миру Ruby. Elixir в использовании гораздо более сложный, чем Ruby (а Phoenix гораздо менее продуктивный в типовых случаях, чем Rails). Сложность окупается кратным ростом возможной производительности с тем же "железом". Из одной экосистемы в другую постоянно идёт взаимопроникновение идей и технологий. Phoenix списывает, творчески перерабатывая под функциональную парадигму (и постепенно в целом радикально переиначивая на свой лад), основную структуру Rails-приложения. Rails списывает экспериментальную и недоработанную идею LiveView (серверных обновлений клиентских событий) у Phoenix, доводит до ума на свой лад и тут же выпускает в production. Phoenix успевает только глазами хлопать. Короче, милые бранятся – только тешатся.
#programming #ruby
Elixir, оттолкнувшись от рубишной базы энтузиастов и заимствовав некоторые элементы внешней эстетики языка Ruby, быстро уходит в свободное плавание. Социально активные рубисты, до которых спустя несколько лет наконец начали доходить слухи о скоропостижной кончине любимого языка, начинают давать восторженные отзывы Elixir-у. Пишутся статьи, переходят разработчики, выступают на Ruby-конференциях с обзором новой модной темы. Через пару лет возвращаются обратно на Ruby.
Elixir и Phoenix занимают свою, пока что ещё не до конца устоявшуюся, нишу в мире веб-разработки. Rails – это "через пять лет вырастем до 100 тыс. пользователей". Elixir – это "уже сейчас 1 млн. запросов в секунду". Это мир Discord-а, Whatsapp-а, некоторых подсистем серверов онлайн-игр и прочих распределённых приложений. Ниша пересекается с классическими веб-приложениями, но не сильно.
Мир Elixir, по ряду причин, очень конгруентен миру Ruby. Elixir в использовании гораздо более сложный, чем Ruby (а Phoenix гораздо менее продуктивный в типовых случаях, чем Rails). Сложность окупается кратным ростом возможной производительности с тем же "железом". Из одной экосистемы в другую постоянно идёт взаимопроникновение идей и технологий. Phoenix списывает, творчески перерабатывая под функциональную парадигму (и постепенно в целом радикально переиначивая на свой лад), основную структуру Rails-приложения. Rails списывает экспериментальную и недоработанную идею LiveView (серверных обновлений клиентских событий) у Phoenix, доводит до ума на свой лад и тут же выпускает в production. Phoenix успевает только глазами хлопать. Короче, милые бранятся – только тешатся.
#programming #ruby
Хроники смерти Ruby: пик популярности (5/6)
К 2017-2018 годам, через 6 лет после даты смерти (2011) и через 3 года после её публичного объявления (2014), Ruby достигает невиданной популярности. До этой поры будучи в общем-то нишевым языком, "себе на уме", инструментом для сравнительно небольшой группы приверженцев (хоть и постоянно растущей), Ruby/Rails становится абсолютным мейнстримом.
Напомню, что создатель Ruby on Rails, Дэвид Хейнмайер Хэнсон, в своей книге "Getting real" (можно перевести как-то вроде "Становясь реалистичным") писал как владелец небольшой компании другим владельцам (и сотрудникам) небольших компаний: ребята, умерьте аппетиты. Не надо мегаломанских целей типа стать фейсбуком. Поставьте скромную цель. Например, миллион баксов в год. Чистыми.
Не надо стремиться к публикациям в больших журналах, типа Wall Street. Занимайтесь маркетингом в своей нише.
Не надо стремиться купить домен из одного словарного слова. Берите любой подходящий, добавьте "app" если надо. Первый домен для приложения компании: basecamphq.com
Спустя годы, конечно, компания-разработчик Rails покупает домен "basecamp.com".
А уже в наше время купила домен "hey.com" (2020) для своего нового email-сервиса (цена не разглашается; из общих соображений, от сотен тысяч до нескольких миллионов долларов).
Про ряд публикаций в Wall Street и выход книги-бестселлера Rework и не говорю.
В компании Basecamp скромно поясняют, мол, к такому успеху не стремились, но к нему пришли.
Следом за успехом материнской компании, получает свои 15 минут славы и разработанный ей (с участием открытого сообщества) фреймворк.
Зарплата Ruby on Rails разработчика выходит на первую строку таблицы зарплат веб-разработчиков.
Ruby заходит одной ногой в топ-10 популярных языков. В последующие годы рекорд не побит: болтается с 10 по 15 место.
Феноменальный успех для нишевого языка, который не поддерживает ни одна всемирная корпорация, и который находился под постоянным коллективным прессингом со стороны агитаторов всех конкурентов.
И вот с этого момента, наконец, можно считать Ruby состоявшимся языком, который хотя бы в теории может начать умирать. По-моему, плато действительно пройдено. Что же, C++ умирает 25 лет. Java умирает 20 лет. .NET умирает 15 лет. Ну и Ruby ещё покочевряжится немножко, как минимум пока нынешние первокурсники не станут шестидесятилетними старичками и не уйдут на пенсию. Не трудно заметить, что период умирания языка в несколько раз превышает период его бурной молодости, так что ждать придётся долго.
Внезапно став мейнстримом, Ruby, из-за своей специализированности и, в некоторой мере, "сиротства" (ни одна всемирная корпорация не поддерживает язык, в отличие от практически любого другого популярного), занял позиции позади навязываемых организационно-административными мерами C++, Go, PHP, Python и др. в индексе "народной популярности" Stackoverflow (последний стал использоваться в качестве основного демагогического аргумента "бесконечного умирания" Ruby).
Зацените накал полемики: Ruby только-только дорос, по масштабам внедрения и популярности, до целесообразности попытки штурма Топ-10 рейтинга Stackoverflow. А отношение такое, как будто он уже успел влезть на первое место и оттуда скатиться на десятое. Откуда такая паника-то? Спокойней надо относиться, ребята, сдержанней.
Объективно, у Ruby/Rails есть существенный недостаток. Если на C++, Javaили КОБОЛе десять дедушек могут полтора года "строить архитектуру", "внедрять паттерны", "документировать и проектировать", вместо реализации бизнес-задач, то на Ruby два студента-старшекурсника за месяц делают MVP. Дедушке не хочется Ruby, ему хочется спокойной жизни. Дедушка напишет в блог, мол, я сорок лет в индустрии, пережил смерть алгола, кобола, эйпиэля, паскаля, ады и перла. И руби тоже туда отправится. Переживу.
Может быть.
Но рассмотрим второй вариант: дедушку самого отправят на пенсию.
На что ставим?
#programming #ruby
К 2017-2018 годам, через 6 лет после даты смерти (2011) и через 3 года после её публичного объявления (2014), Ruby достигает невиданной популярности. До этой поры будучи в общем-то нишевым языком, "себе на уме", инструментом для сравнительно небольшой группы приверженцев (хоть и постоянно растущей), Ruby/Rails становится абсолютным мейнстримом.
Напомню, что создатель Ruby on Rails, Дэвид Хейнмайер Хэнсон, в своей книге "Getting real" (можно перевести как-то вроде "Становясь реалистичным") писал как владелец небольшой компании другим владельцам (и сотрудникам) небольших компаний: ребята, умерьте аппетиты. Не надо мегаломанских целей типа стать фейсбуком. Поставьте скромную цель. Например, миллион баксов в год. Чистыми.
Не надо стремиться к публикациям в больших журналах, типа Wall Street. Занимайтесь маркетингом в своей нише.
Не надо стремиться купить домен из одного словарного слова. Берите любой подходящий, добавьте "app" если надо. Первый домен для приложения компании: basecamphq.com
Спустя годы, конечно, компания-разработчик Rails покупает домен "basecamp.com".
А уже в наше время купила домен "hey.com" (2020) для своего нового email-сервиса (цена не разглашается; из общих соображений, от сотен тысяч до нескольких миллионов долларов).
Про ряд публикаций в Wall Street и выход книги-бестселлера Rework и не говорю.
В компании Basecamp скромно поясняют, мол, к такому успеху не стремились, но к нему пришли.
Следом за успехом материнской компании, получает свои 15 минут славы и разработанный ей (с участием открытого сообщества) фреймворк.
Зарплата Ruby on Rails разработчика выходит на первую строку таблицы зарплат веб-разработчиков.
Ruby заходит одной ногой в топ-10 популярных языков. В последующие годы рекорд не побит: болтается с 10 по 15 место.
Феноменальный успех для нишевого языка, который не поддерживает ни одна всемирная корпорация, и который находился под постоянным коллективным прессингом со стороны агитаторов всех конкурентов.
И вот с этого момента, наконец, можно считать Ruby состоявшимся языком, который хотя бы в теории может начать умирать. По-моему, плато действительно пройдено. Что же, C++ умирает 25 лет. Java умирает 20 лет. .NET умирает 15 лет. Ну и Ruby ещё покочевряжится немножко, как минимум пока нынешние первокурсники не станут шестидесятилетними старичками и не уйдут на пенсию. Не трудно заметить, что период умирания языка в несколько раз превышает период его бурной молодости, так что ждать придётся долго.
Внезапно став мейнстримом, Ruby, из-за своей специализированности и, в некоторой мере, "сиротства" (ни одна всемирная корпорация не поддерживает язык, в отличие от практически любого другого популярного), занял позиции позади навязываемых организационно-административными мерами C++, Go, PHP, Python и др. в индексе "народной популярности" Stackoverflow (последний стал использоваться в качестве основного демагогического аргумента "бесконечного умирания" Ruby).
Зацените накал полемики: Ruby только-только дорос, по масштабам внедрения и популярности, до целесообразности попытки штурма Топ-10 рейтинга Stackoverflow. А отношение такое, как будто он уже успел влезть на первое место и оттуда скатиться на десятое. Откуда такая паника-то? Спокойней надо относиться, ребята, сдержанней.
Объективно, у Ruby/Rails есть существенный недостаток. Если на C++, Java
Может быть.
Но рассмотрим второй вариант: дедушку самого отправят на пенсию.
На что ставим?
#programming #ruby
Хроники умирания Ruby: 2020 и далее (6/6)
К 2020 году Ruby-сообщество окончательно пришло к выводу, что статус первоклассного языка, который был присвоен Ruby "явочным порядком" и без инициативы самого сообщества, накладывает некоторые обязательства, которые невольно надо пытаться выполнять. В частности, поддерживать градус ответной демагогии на должном уровне.
В прошлом году одна из крупнейших PHP-конференций не состоялась, потому что пару разработчиков-феминисток "выразили озабоченность" в связи с "недостаточным разнообразием [diversity]" спикеров. Организатор конференции, глупо хлопая глазами, оправдывался: "Да я... да вы что... да я же приглашал... да просто не было женщин желающих...". На что ему блюстители дайвёрсити строго, сдерживая справедливое раздражение, бросали: "Лучше искать надо было."
В этом плане у Ruby-сообщества несомненный бонус в виде создателя языка-японца и его коллег. Впрочем, как мы видим на примере Cyberpunk, даже при такой казалось бы железобетонной страховке, всерьёз начать докапываться всё равно могут. Но в ином случае было бы совсем плохо, с другой стороны.
Вообще, первая конференция по Ruby, на которую я пришёл, выглядела так: примерно десять человек в Москве встретились у метро. Списались через тематическую Google-группу. Один из участников заранее договорился со своим институтом (не первой величины), выделили кабинет, допустили на территорию. По очереди несколько человек о чём-то интересном рассказали, пиша мелом на доске. Про RSpec доклад был, про то, про сё. Поболтали душевно.
Одна из недавних конференций выглядела до локдауна вы сами знаете как. Официальные спонсоры. Огромная территория, снятая на несколько дней в пригороде. Тысячи участников. Докладчики первой величины со всего мира.
Попробуйте представить теперь, как я воспринимаю назойливо муссируемую идею о том, что Ruby, оказывается, умирает все эти годы. Моей первой реакцией является просто плюнуть и покрутить пальцем у виска: клинический неадекват. Но вот ради молодёжи (не в смысле возраста, а в смысле причастности к теме), которая не виновата в своей начальной неосведомлённости, решил расписать эту мысль чуть подробней.
Собственно, примерно такая же реакция у пока не до конца сориентировавшихся в "социальной реальности" зарубежных коллег. Пишутся статьи со сдержанным недоумением, мол, ребята, что вы нам сказки-то рассказываете: например, про низкую производительность Ruby/Rails? По сравнению с чем низкая? Уж не хуже, например, чем у Python/Django и PHP/Laravel.
"Не хуже" – это, конечно, вежливая сдержанность взрослого, чтобы не обидеть навязчивых подростков. Следующим бесхитростным ходом в борьбе инженеров с журналистами является такой: "А теперь Ruby стал в три раза быстрей. Третья версия." Мол, ну да, умираем, виноваты-с. Кочевряжимся вот как-то так, простите.
Ответным контр-ходом является вариация на тему "вы всё врёти", а именно мантра следующего сорта: "каждый инструмент подходит под свою задачу, нельзя однобоко смотреть на вещи, инженер должен уметь пользоваться чем дают, программист может изучить язык за две недели" и т.п.
На что инженер будет недоумённо хмуриться: мол, простите, а зачем мне кто-то будет рассказывать, что я должен говорить и даже думать(!), если я могу сам всё попробовать и объективно сравнить?
Сравнительный анализ инструментов для конкретной ниши разработки веб-приложений (в широком смысле) показывает, что Ruby/Rails – это самый технологичный инструмент на сегодняшний день. Вообще, на самом деле, рубисты плевать хотели и на Ruby, и на Rails, и не так уж сильно, открою секрет, любят эти технологии.
"Культ Rails" это "культ острых ножей для нарезания хлеба". "Почему ты острым ножом режешь, ведь есть десять тупых?" – "Ну дык, это, удобней ить" – "Ты, как инженер, должен уметь использовать разные инструменты, смотреть на технологии объективно, научиться пользоваться другим ножом можно за пару дней..." и пошло-поехало.
#programming #ruby
К 2020 году Ruby-сообщество окончательно пришло к выводу, что статус первоклассного языка, который был присвоен Ruby "явочным порядком" и без инициативы самого сообщества, накладывает некоторые обязательства, которые невольно надо пытаться выполнять. В частности, поддерживать градус ответной демагогии на должном уровне.
В прошлом году одна из крупнейших PHP-конференций не состоялась, потому что пару разработчиков-феминисток "выразили озабоченность" в связи с "недостаточным разнообразием [diversity]" спикеров. Организатор конференции, глупо хлопая глазами, оправдывался: "Да я... да вы что... да я же приглашал... да просто не было женщин желающих...". На что ему блюстители дайвёрсити строго, сдерживая справедливое раздражение, бросали: "Лучше искать надо было."
В этом плане у Ruby-сообщества несомненный бонус в виде создателя языка-японца и его коллег. Впрочем, как мы видим на примере Cyberpunk, даже при такой казалось бы железобетонной страховке, всерьёз начать докапываться всё равно могут. Но в ином случае было бы совсем плохо, с другой стороны.
Вообще, первая конференция по Ruby, на которую я пришёл, выглядела так: примерно десять человек в Москве встретились у метро. Списались через тематическую Google-группу. Один из участников заранее договорился со своим институтом (не первой величины), выделили кабинет, допустили на территорию. По очереди несколько человек о чём-то интересном рассказали, пиша мелом на доске. Про RSpec доклад был, про то, про сё. Поболтали душевно.
Одна из недавних конференций выглядела до локдауна вы сами знаете как. Официальные спонсоры. Огромная территория, снятая на несколько дней в пригороде. Тысячи участников. Докладчики первой величины со всего мира.
Попробуйте представить теперь, как я воспринимаю назойливо муссируемую идею о том, что Ruby, оказывается, умирает все эти годы. Моей первой реакцией является просто плюнуть и покрутить пальцем у виска: клинический неадекват. Но вот ради молодёжи (не в смысле возраста, а в смысле причастности к теме), которая не виновата в своей начальной неосведомлённости, решил расписать эту мысль чуть подробней.
Собственно, примерно такая же реакция у пока не до конца сориентировавшихся в "социальной реальности" зарубежных коллег. Пишутся статьи со сдержанным недоумением, мол, ребята, что вы нам сказки-то рассказываете: например, про низкую производительность Ruby/Rails? По сравнению с чем низкая? Уж не хуже, например, чем у Python/Django и PHP/Laravel.
"Не хуже" – это, конечно, вежливая сдержанность взрослого, чтобы не обидеть навязчивых подростков. Следующим бесхитростным ходом в борьбе инженеров с журналистами является такой: "А теперь Ruby стал в три раза быстрей. Третья версия." Мол, ну да, умираем, виноваты-с. Кочевряжимся вот как-то так, простите.
Ответным контр-ходом является вариация на тему "вы всё врёти", а именно мантра следующего сорта: "каждый инструмент подходит под свою задачу, нельзя однобоко смотреть на вещи, инженер должен уметь пользоваться чем дают, программист может изучить язык за две недели" и т.п.
На что инженер будет недоумённо хмуриться: мол, простите, а зачем мне кто-то будет рассказывать, что я должен говорить и даже думать(!), если я могу сам всё попробовать и объективно сравнить?
Сравнительный анализ инструментов для конкретной ниши разработки веб-приложений (в широком смысле) показывает, что Ruby/Rails – это самый технологичный инструмент на сегодняшний день. Вообще, на самом деле, рубисты плевать хотели и на Ruby, и на Rails, и не так уж сильно, открою секрет, любят эти технологии.
"Культ Rails" это "культ острых ножей для нарезания хлеба". "Почему ты острым ножом режешь, ведь есть десять тупых?" – "Ну дык, это, удобней ить" – "Ты, как инженер, должен уметь использовать разные инструменты, смотреть на технологии объективно, научиться пользоваться другим ножом можно за пару дней..." и пошло-поехало.
#programming #ruby
Я думаю, всё так и будет продолжаться примерно также, как идёт. Ruby будет "умирать", отмечая по ходу дела всё новые технические свершения. Особой популярности не будет (дедушки не хотят в кризис на пенсию), но и без особых провалов обойдётся. Rails приносит деньги. Миллиардерам деньги не нужны, за идею работают, а вот миллионерам (которые и финансируют разработку Ruby и Rails) очень даже нужны.
Миллионеры, конечно, тоже не сахар. И периодические шуточки DHH (известное добавление метода thirty_third или приколачивание ActionText прямо внутрь Rails) терпеть неприятно. Диалектику из серии: "А почему вы внедрили какой-то колхозный метод для запуска такого-то SQL-запроса, если три года назад трудящиеся вам присылали два варианта PR с нормальной реализацией (которые были отклонены)" - "А потому" – тоже. Возникает грустный вопрос в адрес всех этих JS/Node, Python/Django, PHP/Laravel, Java/Spring и остальных "трендов стековерфлоу": ребята, почему за 16 лет существования Ruby on Rails, в ряде случаев прямо заявив попытку скопировать Rails на своём языке, у вас не получилось ничего толкового? Ответа нет. Поэтому приходится терпеть.
#programming #ruby
Миллионеры, конечно, тоже не сахар. И периодические шуточки DHH (известное добавление метода thirty_third или приколачивание ActionText прямо внутрь Rails) терпеть неприятно. Диалектику из серии: "А почему вы внедрили какой-то колхозный метод для запуска такого-то SQL-запроса, если три года назад трудящиеся вам присылали два варианта PR с нормальной реализацией (которые были отклонены)" - "А потому" – тоже. Возникает грустный вопрос в адрес всех этих JS/Node, Python/Django, PHP/Laravel, Java/Spring и остальных "трендов стековерфлоу": ребята, почему за 16 лет существования Ruby on Rails, в ряде случаев прямо заявив попытку скопировать Rails на своём языке, у вас не получилось ничего толкового? Ответа нет. Поэтому приходится терпеть.
#programming #ruby
Очередная новость: Гугл пожертвует $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