Вы систематически путаете компании (юрлица) и проекты (дистрибутивы, исходный код). PostgreSQL - это проект, а не компания. Нет юрлица, которому он принадлежит. И не продался Постгрес крупному бизнесу не потому, что майнтейнеры работали в одной сильной и независимой компании (ее просто не было), а потому, что работали в разных, в том числе, крупных, компаниях. И ни одна компания не смогла ни получить права решающего голоса в коллективе майнтейнеров, ни “утопить” свободную версию PostgreSQL, чтобы заменить ее своей, проприетарной версией.
Кстати, даже если бы такая компания нашлась, не факт, что ей удалось бы удержать власть. Именно в силу лицензии. Подобную историю мы могли наблюдать с nodejs (гуглить joyent и io.js).
PostgreSQL и Postgres Pro уникальны тем, что они не продались крупному бизнесу, а с самого основания (30 лет подряд) вполне успешно пытаются вести дела самостоятельно как независимая компания.
Вы что-то путаете, PostgreSQL и Postgres Pro - это не компании. А компания Postgres Professional существует, очевидно, сильно меньше 30 лет.
Специально искал комментарий про Постгрес. Для тех, кто не сильно следит за этой СУБД, могут быть не очевидны несколько фактов:
Постгрес родом из того же Беркли.
Изначально распространялся под лицензией BSD, да и нынешняя лицензия имеет прямые родственные с ней связи.
В сообществе Постгрес приветствуется свобода делать закрытые форки, т.к. практика показала - им выгодно, по разным причинам, делать вклад в основную ветку.
Не знаю, что там на самом деле, но могу предположить и прямо противоположную проблему: из-за бурного роста часть инженеров могла перейти на менеджерские позиции и проявить себя там, скажем так, хуже, чем в роли инженеров. А теперь эту ошибку исправляют.
Вы рассуждаете о сферической автоматизации в вакууме. В реальном же мире все куда прозаичнее: после автоматизации бардака сопротивление попыткам навести порядок только вырастет - теперь упираться будет еще и система автоматизации.
Так вы посмотрите, что было раньше: те самые черные списки, которыми банки обменивались между собой. А БКИ появились уже позже, как способ ввести данную потребность банков в правовое поле.
Можно предположить, что рынок труда просто дозревает медленнее кредитного рынка. И будут нам и черные списки, и "Бюро трудовой истории"...
Интересно, практикует ли кто-нибудь такой метод, как запрос рекомендаций с предыдущего места работы? Помогает? По идее, если человек работал на одном месте больше года, несоответствие образа реальным результатам должно раскрыться.
"Начинающим" программистам не нужна стройная система знаний. Им нужна практика, им нужно "заговорить" на новом языке, не вдаваясь в ньюансы что такое там этот statement - выражение/оператор/инструкция/утверждение или ещё что-то.
Так ведь именно для того, чтобы быстро "заговорить" на новом для себя языке программирования, и нужна стройная система знаний. Например, когда я был студентом, нас больше года плотно терроризировали моделями вычислений, нотациями определения языков, в том числе все эти statements и operators, а потом за несколько занятий дали что-то около 20 языков. После этого конкретным языкам уже не учили, справедливо считая, что студент справится с этим сам.
Возможно, столкновение позиций тут происходит из-за того, кого считать "начинающим". Если я правильно понял, Вы имеете ввиду тех, кто недавно написал свой первый hello world. Тут можно только согласиться: абстрактная теория, которая никак не вяжется с личным опытом, скорее оттолкнет от программирования, чем поможет его освоить.
Но с другой стороны, даже выпускник ВУЗа, который начал программировать еще в школе, со всеми основаниями может считаться начинающим. И этому товарищу от стройной системы знаний одна сплошная польза.
Поразмышлял на досуге над подходом. Что, на мой взгляд, однозначно интересно: если взять за аксиому отказ от тотальной типизации и поставить вопрос о том, как может выглядеть разумная частичная типизация, то в первую очередь на ум приходят именно контракты на границах сервисов, библиотек, модулей. Причем это даже не будет стоить сильно дорого, т.к. документировать и тестировать эти границы все равно надо, и речь только о том, чтобы делать это понятным в т.ч. и для IDE способом. Идею, как Вы это сделали в своем проекте я понял, думаю, у себя ее воспроизвести тоже смогу, когда дозрею.
В любом случае, спасибо за публикацию своих идей! Последующие публикации на тему пока не смотрел, но, видимо, еще посмотрю :)
Хорошая статья. Еще можно добавить, что рассеянное мышление возможно и без отвлечения от работы.
У меня был случай: надо было разобраться в одной статье по компьютерной лингвистике. Ее автор писал для своих, кто "в теме", но мне эта область была тогда совсем незнакома. Читаю первое предложение и не понимаю ничего. Читаю его еще раз — эффект тот же. В итоге оставил попытки что-то понять и просто прочитал эту статью о зюзрях и хухрях от начала до конца несколько раз. Раз то ли на четвертый, то ли на пятый смысл текста как-то сам собой прояснился, и осталось только разобраться с деталями.
Если что, отказываться от отдыха не призываю. Мысль, скорее, в обратном: даже когда занят делом, полная концентрация иногда может мешать.
Не существует буквально ни одного примера в этой самой индустрии, где первый забрал всё.
olegchir:
Например, Oracle Database убила гораздо более качественный Ingress.
С учетом того, что Ingres сильно старше Oracle Database, у вас получилось не возражение, а подтверждение тезиса. А с учетом того, что Ingres затем переродился в Postgres, становится еще более неочевидно, кто, что и каким по счету забрал.
Такой наглости я еще не встречал :) Аппелировать к стохастически порожденным текстам в споре о точных вещах.
"Гедель утверждает существование формулы в арифметике, которую нельзя ни доказать, ни опровергнуть." - это абсолютно точное утверждение, являющееся частным случаем теоремы, которого мне достаточно, чтобы опровергнуть ваше якобы доказательство.
Остальное фуфло от дипсика разбирать лень. Всего хорошего.
Ваша статья про первую теорему Геделя о неполноте демонстрирует, что вы не поняли даже формулировку этой теоремы.
Гедель утверждает существование формулы в арифметике, которую нельзя ни доказать, ни опровергнуть.
А у вас арифметика превратилась в "любую непротиворечивую систему утверждений" - с этим и сам Гедель не согласен в свой теореме о полноте классической логики, в которой множество тавтологий вообще-то тоже - непротиворечивая система утверждений.
И еще "невозможность опровергнуть" с какого-то перепугу превратилась в "правдивость". Для справедливости такой замены сначала надо доказать полноту. Вот для классической логики эту полноту Гедель доказал, там можно ставить знак равенства между неопровержимостью и истинностью. А в арифметике - нельзя. Тоже Гедель доказал.
Поэтому опровергаете вы там что угодно, но не теорему Геделя.
Коллеги, как вы определяете точку, где пора остановить рефакторинг и переключиться на перепроектирование границ? Есть ли у вас метрики (типа коэффициента связности сервисов) или больше через боль и крики бизнеса?
По-моему опыту, на первое место надо ставить здравый смысл. А метрики и разные аббревиатуры нужны только, чтобы убедиться, что здравый смысл не зарулил куда-то не туда.
Например, сервис нотификаций вызывал 5 других сервисов через цепочку RPC, чтобы собрать данные для письма — латенси ползла в ..
От подобных неприятных сюрпризов защищает очень простой прием: всегда моделируйте потоки данных. Даже если это монолит, поток данных между сервером приложений и БД нуждается в контроле не меньше, чем между клиентом и сервером приложений. Если вы сначала проектируете API и только потом его реализуете, то вся необходимая информация должна быть уже на этапе проекта: берем каждую точку внешнего API; отслеживаем полный граф вызовов для выполнения запроса к этой точке; честно отвечаем себе, является ли этот граф разумным.
Если вы работаете в конторе, где менеджмент предпочитает метрики здравому смыслу, этот прием можно упаковать во что-нибудь типа "длина типичного (кратчайшего, наихудшего) пути выполнения запроса", который считать для каждого типа запроса по количеству пересечений границ сервисов, совершаемых потоками данных по пути от начала запроса до отправки ответа. Какое значение этой метрики считать хорошим не скажу, сильно зависит и от решаемой задачи, и от условий, в которых она решается. И, разумеется, ее надо не минимизировать (так вы можете прийти только к монолиту), а выставить верхний порог, превышение которого будет сигнализировать о подозрительности архитектуры.
Ну то есть вы не хотите взять на себя труд пояснить для меня сделанное вами утверждение? В такой ситуации я не вижу причин брать на себя труд пояснять что-то для вас.
А вообще, не очень понимаю этот Ваш комментарий. Я даю конструктивное предложение, как улучшить форму подачи Ваших идей для читателя, а Вы мне приветы передаете.
Т.е. Вы решили для демонстрации функционального стиля придумать оператор ":=", который у людей ассоциируется в первую очередь с присваиванием в процедурных языках? Ну ОК. Хотя, на мой взгляд, вопросов было бы меньше, если бы Вы использовали синтаксис какого-нибудь существующего языка или хотя бы использовали разные обозначения для оператора присваивания значения переменной и оператора именования выражения. Например, так:
Вы систематически путаете компании (юрлица) и проекты (дистрибутивы, исходный код). PostgreSQL - это проект, а не компания. Нет юрлица, которому он принадлежит. И не продался Постгрес крупному бизнесу не потому, что майнтейнеры работали в одной сильной и независимой компании (ее просто не было), а потому, что работали в разных, в том числе, крупных, компаниях. И ни одна компания не смогла ни получить права решающего голоса в коллективе майнтейнеров, ни “утопить” свободную версию PostgreSQL, чтобы заменить ее своей, проприетарной версией.
Кстати, даже если бы такая компания нашлась, не факт, что ей удалось бы удержать власть. Именно в силу лицензии. Подобную историю мы могли наблюдать с nodejs (гуглить joyent и io.js).
Вы что-то путаете, PostgreSQL и Postgres Pro - это не компании. А компания Postgres Professional существует, очевидно, сильно меньше 30 лет.
Специально искал комментарий про Постгрес. Для тех, кто не сильно следит за этой СУБД, могут быть не очевидны несколько фактов:
Постгрес родом из того же Беркли.
Изначально распространялся под лицензией BSD, да и нынешняя лицензия имеет прямые родственные с ней связи.
В сообществе Постгрес приветствуется свобода делать закрытые форки, т.к. практика показала - им выгодно, по разным причинам, делать вклад в основную ветку.
Не знаю, что там на самом деле, но могу предположить и прямо противоположную проблему: из-за бурного роста часть инженеров могла перейти на менеджерские позиции и проявить себя там, скажем так, хуже, чем в роли инженеров. А теперь эту ошибку исправляют.
Вы рассуждаете о сферической автоматизации в вакууме. В реальном же мире все куда прозаичнее: после автоматизации бардака сопротивление попыткам навести порядок только вырастет - теперь упираться будет еще и система автоматизации.
Так вы посмотрите, что было раньше: те самые черные списки, которыми банки обменивались между собой. А БКИ появились уже позже, как способ ввести данную потребность банков в правовое поле.
Можно предположить, что рынок труда просто дозревает медленнее кредитного рынка. И будут нам и черные списки, и "Бюро трудовой истории"...
Ну банки же как-то договорились о кредитных историях.
Интересно, практикует ли кто-нибудь такой метод, как запрос рекомендаций с предыдущего места работы? Помогает? По идее, если человек работал на одном месте больше года, несоответствие образа реальным результатам должно раскрыться.
Так ведь именно для того, чтобы быстро "заговорить" на новом для себя языке программирования, и нужна стройная система знаний. Например, когда я был студентом, нас больше года плотно терроризировали моделями вычислений, нотациями определения языков, в том числе все эти statements и operators, а потом за несколько занятий дали что-то около 20 языков. После этого конкретным языкам уже не учили, справедливо считая, что студент справится с этим сам.
Возможно, столкновение позиций тут происходит из-за того, кого считать "начинающим". Если я правильно понял, Вы имеете ввиду тех, кто недавно написал свой первый hello world. Тут можно только согласиться: абстрактная теория, которая никак не вяжется с личным опытом, скорее оттолкнет от программирования, чем поможет его освоить.
Но с другой стороны, даже выпускник ВУЗа, который начал программировать еще в школе, со всеми основаниями может считаться начинающим. И этому товарищу от стройной системы знаний одна сплошная польза.
В бесконечность прогресса веруете? Ну-ну )
Поразмышлял на досуге над подходом. Что, на мой взгляд, однозначно интересно: если взять за аксиому отказ от тотальной типизации и поставить вопрос о том, как может выглядеть разумная частичная типизация, то в первую очередь на ум приходят именно контракты на границах сервисов, библиотек, модулей. Причем это даже не будет стоить сильно дорого, т.к. документировать и тестировать эти границы все равно надо, и речь только о том, чтобы делать это понятным в т.ч. и для IDE способом. Идею, как Вы это сделали в своем проекте я понял, думаю, у себя ее воспроизвести тоже смогу, когда дозрею.
В любом случае, спасибо за публикацию своих идей! Последующие публикации на тему пока не смотрел, но, видимо, еще посмотрю :)
Хорошая статья. Еще можно добавить, что рассеянное мышление возможно и без отвлечения от работы.
У меня был случай: надо было разобраться в одной статье по компьютерной лингвистике. Ее автор писал для своих, кто "в теме", но мне эта область была тогда совсем незнакома. Читаю первое предложение и не понимаю ничего. Читаю его еще раз — эффект тот же. В итоге оставил попытки что-то понять и просто прочитал эту статью о зюзрях и хухрях от начала до конца несколько раз. Раз то ли на четвертый, то ли на пятый смысл текста как-то сам собой прояснился, и осталось только разобраться с деталями.
Если что, отказываться от отдыха не призываю. Мысль, скорее, в обратном: даже когда занят делом, полная концентрация иногда может мешать.
cupraer:
olegchir:
С учетом того, что Ingres сильно старше Oracle Database, у вас получилось не возражение, а подтверждение тезиса. А с учетом того, что Ingres затем переродился в Postgres, становится еще более неочевидно, кто, что и каким по счету забрал.
Такой наглости я еще не встречал :) Аппелировать к стохастически порожденным текстам в споре о точных вещах.
"Гедель утверждает существование формулы в арифметике, которую нельзя ни доказать, ни опровергнуть." - это абсолютно точное утверждение, являющееся частным случаем теоремы, которого мне достаточно, чтобы опровергнуть ваше якобы доказательство.
Остальное фуфло от дипсика разбирать лень. Всего хорошего.
Ваша статья про первую теорему Геделя о неполноте демонстрирует, что вы не поняли даже формулировку этой теоремы.
Гедель утверждает существование формулы в арифметике, которую нельзя ни доказать, ни опровергнуть.
А у вас арифметика превратилась в "любую непротиворечивую систему утверждений" - с этим и сам Гедель не согласен в свой теореме о полноте классической логики, в которой множество тавтологий вообще-то тоже - непротиворечивая система утверждений.
И еще "невозможность опровергнуть" с какого-то перепугу превратилась в "правдивость". Для справедливости такой замены сначала надо доказать полноту. Вот для классической логики эту полноту Гедель доказал, там можно ставить знак равенства между неопровержимостью и истинностью. А в арифметике - нельзя. Тоже Гедель доказал.
Поэтому опровергаете вы там что угодно, но не теорему Геделя.
По-моему опыту, на первое место надо ставить здравый смысл. А метрики и разные аббревиатуры нужны только, чтобы убедиться, что здравый смысл не зарулил куда-то не туда.
От подобных неприятных сюрпризов защищает очень простой прием: всегда моделируйте потоки данных. Даже если это монолит, поток данных между сервером приложений и БД нуждается в контроле не меньше, чем между клиентом и сервером приложений. Если вы сначала проектируете API и только потом его реализуете, то вся необходимая информация должна быть уже на этапе проекта: берем каждую точку внешнего API; отслеживаем полный граф вызовов для выполнения запроса к этой точке; честно отвечаем себе, является ли этот граф разумным.
Если вы работаете в конторе, где менеджмент предпочитает метрики здравому смыслу, этот прием можно упаковать во что-нибудь типа "длина типичного (кратчайшего, наихудшего) пути выполнения запроса", который считать для каждого типа запроса по количеству пересечений границ сервисов, совершаемых потоками данных по пути от начала запроса до отправки ответа. Какое значение этой метрики считать хорошим не скажу, сильно зависит и от решаемой задачи, и от условий, в которых она решается. И, разумеется, ее надо не минимизировать (так вы можете прийти только к монолиту), а выставить верхний порог, превышение которого будет сигнализировать о подозрительности архитектуры.
Ну то есть вы не хотите взять на себя труд пояснить для меня сделанное вами утверждение? В такой ситуации я не вижу причин брать на себя труд пояснять что-то для вас.
А вообще, не очень понимаю этот Ваш комментарий. Я даю конструктивное предложение, как улучшить форму подачи Ваших идей для читателя, а Вы мне приветы передаете.
Спасибо, им от меня тоже привет. В последнем, к слову, Ваша идея о неизменности состояния тоже демонстрируется нагляднее, чем в Bogus:
В JS декларации (const, let, function и т.д.) не менее важны, чем присваивание (=), на которое Вы сослались.
Т.е. Вы решили для демонстрации функционального стиля придумать оператор ":=", который у людей ассоциируется в первую очередь с присваиванием в процедурных языках? Ну ОК. Хотя, на мой взгляд, вопросов было бы меньше, если бы Вы использовали синтаксис какого-нибудь существующего языка или хотя бы использовали разные обозначения для оператора присваивания значения переменной и оператора именования выражения. Например, так: