Так вы посмотрите, что было раньше: те самые черные списки, которыми банки обменивались между собой. А БКИ появились уже позже, как способ ввести данную потребность банков в правовое поле.
Можно предположить, что рынок труда просто дозревает медленнее кредитного рынка. И будут нам и черные списки, и "Бюро трудовой истории"...
Интересно, практикует ли кто-нибудь такой метод, как запрос рекомендаций с предыдущего места работы? Помогает? По идее, если человек работал на одном месте больше года, несоответствие образа реальным результатам должно раскрыться.
"Начинающим" программистам не нужна стройная система знаний. Им нужна практика, им нужно "заговорить" на новом языке, не вдаваясь в ньюансы что такое там этот statement - выражение/оператор/инструкция/утверждение или ещё что-то.
Так ведь именно для того, чтобы быстро "заговорить" на новом для себя языке программирования, и нужна стройная система знаний. Например, когда я был студентом, нас больше года плотно терроризировали моделями вычислений, нотациями определения языков, в том числе все эти statements и operators, а потом за несколько занятий дали что-то около 20 языков. После этого конкретным языкам уже не учили, справедливо считая, что студент справится с этим сам.
Возможно, столкновение позиций тут происходит из-за того, кого считать "начинающим". Если я правильно понял, Вы имеете ввиду тех, кто недавно написал свой первый hello world. Тут можно только согласиться: абстрактная теория, которая никак не вяжется с личным опытом, скорее оттолкнет от программирования, чем поможет его освоить.
Но с другой стороны, даже выпускник ВУЗа, который начал программировать еще в школе, со всеми основаниями может считаться начинающим. И этому товарищу от стройной системы знаний одна сплошная польза.
Поразмышлял на досуге над подходом. Что, на мой взгляд, однозначно интересно: если взять за аксиому отказ от тотальной типизации и поставить вопрос о том, как может выглядеть разумная частичная типизация, то в первую очередь на ум приходят именно контракты на границах сервисов, библиотек, модулей. Причем это даже не будет стоить сильно дорого, т.к. документировать и тестировать эти границы все равно надо, и речь только о том, чтобы делать это понятным в т.ч. и для IDE способом. Идею, как Вы это сделали в своем проекте я понял, думаю, у себя ее воспроизвести тоже смогу, когда дозрею.
В любом случае, спасибо за публикацию своих идей! Последующие публикации на тему пока не смотрел, но, видимо, еще посмотрю :)
Хорошая статья. Еще можно добавить, что рассеянное мышление возможно и без отвлечения от работы.
У меня был случай: надо было разобраться в одной статье по компьютерной лингвистике. Ее автор писал для своих, кто "в теме", но мне эта область была тогда совсем незнакома. Читаю первое предложение и не понимаю ничего. Читаю его еще раз — эффект тот же. В итоге оставил попытки что-то понять и просто прочитал эту статью о зюзрях и хухрях от начала до конца несколько раз. Раз то ли на четвертый, то ли на пятый смысл текста как-то сам собой прояснился, и осталось только разобраться с деталями.
Если что, отказываться от отдыха не призываю. Мысль, скорее, в обратном: даже когда занят делом, полная концентрация иногда может мешать.
Не существует буквально ни одного примера в этой самой индустрии, где первый забрал всё.
olegchir:
Например, Oracle Database убила гораздо более качественный Ingress.
С учетом того, что Ingres сильно старше Oracle Database, у вас получилось не возражение, а подтверждение тезиса. А с учетом того, что Ingres затем переродился в Postgres, становится еще более неочевидно, кто, что и каким по счету забрал.
Такой наглости я еще не встречал :) Аппелировать к стохастически порожденным текстам в споре о точных вещах.
"Гедель утверждает существование формулы в арифметике, которую нельзя ни доказать, ни опровергнуть." - это абсолютно точное утверждение, являющееся частным случаем теоремы, которого мне достаточно, чтобы опровергнуть ваше якобы доказательство.
Остальное фуфло от дипсика разбирать лень. Всего хорошего.
Ваша статья про первую теорему Геделя о неполноте демонстрирует, что вы не поняли даже формулировку этой теоремы.
Гедель утверждает существование формулы в арифметике, которую нельзя ни доказать, ни опровергнуть.
А у вас арифметика превратилась в "любую непротиворечивую систему утверждений" - с этим и сам Гедель не согласен в свой теореме о полноте классической логики, в которой множество тавтологий вообще-то тоже - непротиворечивая система утверждений.
И еще "невозможность опровергнуть" с какого-то перепугу превратилась в "правдивость". Для справедливости такой замены сначала надо доказать полноту. Вот для классической логики эту полноту Гедель доказал, там можно ставить знак равенства между неопровержимостью и истинностью. А в арифметике - нельзя. Тоже Гедель доказал.
Поэтому опровергаете вы там что угодно, но не теорему Геделя.
Коллеги, как вы определяете точку, где пора остановить рефакторинг и переключиться на перепроектирование границ? Есть ли у вас метрики (типа коэффициента связности сервисов) или больше через боль и крики бизнеса?
По-моему опыту, на первое место надо ставить здравый смысл. А метрики и разные аббревиатуры нужны только, чтобы убедиться, что здравый смысл не зарулил куда-то не туда.
Например, сервис нотификаций вызывал 5 других сервисов через цепочку RPC, чтобы собрать данные для письма — латенси ползла в ..
От подобных неприятных сюрпризов защищает очень простой прием: всегда моделируйте потоки данных. Даже если это монолит, поток данных между сервером приложений и БД нуждается в контроле не меньше, чем между клиентом и сервером приложений. Если вы сначала проектируете API и только потом его реализуете, то вся необходимая информация должна быть уже на этапе проекта: берем каждую точку внешнего API; отслеживаем полный граф вызовов для выполнения запроса к этой точке; честно отвечаем себе, является ли этот граф разумным.
Если вы работаете в конторе, где менеджмент предпочитает метрики здравому смыслу, этот прием можно упаковать во что-нибудь типа "длина типичного (кратчайшего, наихудшего) пути выполнения запроса", который считать для каждого типа запроса по количеству пересечений границ сервисов, совершаемых потоками данных по пути от начала запроса до отправки ответа. Какое значение этой метрики считать хорошим не скажу, сильно зависит и от решаемой задачи, и от условий, в которых она решается. И, разумеется, ее надо не минимизировать (так вы можете прийти только к монолиту), а выставить верхний порог, превышение которого будет сигнализировать о подозрительности архитектуры.
Ну то есть вы не хотите взять на себя труд пояснить для меня сделанное вами утверждение? В такой ситуации я не вижу причин брать на себя труд пояснять что-то для вас.
А вообще, не очень понимаю этот Ваш комментарий. Я даю конструктивное предложение, как улучшить форму подачи Ваших идей для читателя, а Вы мне приветы передаете.
Т.е. Вы решили для демонстрации функционального стиля придумать оператор ":=", который у людей ассоциируется в первую очередь с присваиванием в процедурных языках? Ну ОК. Хотя, на мой взгляд, вопросов было бы меньше, если бы Вы использовали синтаксис какого-нибудь существующего языка или хотя бы использовали разные обозначения для оператора присваивания значения переменной и оператора именования выражения. Например, так:
Вы утверждаете, что после устранения сахара (записи вызова метода в синтаксической форме инфиксного оператора) сахара стала больше. Позвольте поинтересоваться, что Вы считаете сахаром, что - сахарным песком? И как их отличаете от "безуглеводного" кода?
next( prev ) := prev + one что такое "+", это же вроде бы не функция? А что это такое? Где у них типа-безопасность, например?
Вроде как функциональные вычисления тоже не совсем функциональные?
Там конечно надо смотреть исходники, вероятно, какой-нибудь Scala, где, скорее всего, после устранения сахара, окажется что-то вроде: next( prev ).assign(prev.plus(one))
Буквально: ":=" - это метод объекта, который вернуло выражение next( prev ). А "+" - это метод объекта prev. Обеспечению типобезопасности тут синтаксис никак не мешает. Нужно всего лишь смириться, что привычные символы могут означать что-то очень необычное, просто потому, что так решил автор конкретного метода "+".
Свои проекты публично показать не могу, поэтому, если Вы действительно хотите поделиться своими идеями с сообществом, можете показать свой пример реализации Контейнера Объектов. У Вас, как я понял, все лежит в публичных репозиториях? Можно просто накидать ссылок, где какие части реализации смотреть, на что стоит обратить особое внимание, и т.д.
Тут, похоже, я неточно выразился. Я не призываю описывать недостатки JS. Но мы все знаем, что типизация в js - это едва ли не самое критикуемое из слабых мест языка. А из принципов, на которых должна строиться разработка, трудно извлечь конкретику, как же этот недостаток может быть преодолен. Этому внимание уделено весьма вскользь: JSDoc, контракты. Причем в размытых формулировках, из которых лично мне было мало что понятно, пока Вы не добавили уточнений в комментариях. Тут логика очень простая: вот я, например, тоже фуллстек и тоже пишу на js. Относительно небольшие проекты я совершенно точно буду писать на js. А большие, где сделать качественный code review в одно лицо уже точно не получится (для меня это примерно 10 тысяч сущностей, у Вас может быть больше, но где-то этот порог все равно есть), сопряжены с компромиссами, болью и костылями. Может я такие проекты просто не умею готовить? Возможно. Но и в предложенной статье рецепта приготовления я не увидел. И будь в ограничениях к принципам сказано что-то еще про размер проектов, на которых это работает - придраться, пожалуй, было бы не к чему.
Так вы посмотрите, что было раньше: те самые черные списки, которыми банки обменивались между собой. А БКИ появились уже позже, как способ ввести данную потребность банков в правовое поле.
Можно предположить, что рынок труда просто дозревает медленнее кредитного рынка. И будут нам и черные списки, и "Бюро трудовой истории"...
Ну банки же как-то договорились о кредитных историях.
Интересно, практикует ли кто-нибудь такой метод, как запрос рекомендаций с предыдущего места работы? Помогает? По идее, если человек работал на одном месте больше года, несоответствие образа реальным результатам должно раскрыться.
Так ведь именно для того, чтобы быстро "заговорить" на новом для себя языке программирования, и нужна стройная система знаний. Например, когда я был студентом, нас больше года плотно терроризировали моделями вычислений, нотациями определения языков, в том числе все эти statements и operators, а потом за несколько занятий дали что-то около 20 языков. После этого конкретным языкам уже не учили, справедливо считая, что студент справится с этим сам.
Возможно, столкновение позиций тут происходит из-за того, кого считать "начинающим". Если я правильно понял, Вы имеете ввиду тех, кто недавно написал свой первый hello world. Тут можно только согласиться: абстрактная теория, которая никак не вяжется с личным опытом, скорее оттолкнет от программирования, чем поможет его освоить.
Но с другой стороны, даже выпускник ВУЗа, который начал программировать еще в школе, со всеми основаниями может считаться начинающим. И этому товарищу от стройной системы знаний одна сплошная польза.
В бесконечность прогресса веруете? Ну-ну )
Поразмышлял на досуге над подходом. Что, на мой взгляд, однозначно интересно: если взять за аксиому отказ от тотальной типизации и поставить вопрос о том, как может выглядеть разумная частичная типизация, то в первую очередь на ум приходят именно контракты на границах сервисов, библиотек, модулей. Причем это даже не будет стоить сильно дорого, т.к. документировать и тестировать эти границы все равно надо, и речь только о том, чтобы делать это понятным в т.ч. и для IDE способом. Идею, как Вы это сделали в своем проекте я понял, думаю, у себя ее воспроизвести тоже смогу, когда дозрею.
В любом случае, спасибо за публикацию своих идей! Последующие публикации на тему пока не смотрел, но, видимо, еще посмотрю :)
Хорошая статья. Еще можно добавить, что рассеянное мышление возможно и без отвлечения от работы.
У меня был случай: надо было разобраться в одной статье по компьютерной лингвистике. Ее автор писал для своих, кто "в теме", но мне эта область была тогда совсем незнакома. Читаю первое предложение и не понимаю ничего. Читаю его еще раз — эффект тот же. В итоге оставил попытки что-то понять и просто прочитал эту статью о зюзрях и хухрях от начала до конца несколько раз. Раз то ли на четвертый, то ли на пятый смысл текста как-то сам собой прояснился, и осталось только разобраться с деталями.
Если что, отказываться от отдыха не призываю. Мысль, скорее, в обратном: даже когда занят делом, полная концентрация иногда может мешать.
cupraer:
olegchir:
С учетом того, что Ingres сильно старше Oracle Database, у вас получилось не возражение, а подтверждение тезиса. А с учетом того, что Ingres затем переродился в Postgres, становится еще более неочевидно, кто, что и каким по счету забрал.
Такой наглости я еще не встречал :) Аппелировать к стохастически порожденным текстам в споре о точных вещах.
"Гедель утверждает существование формулы в арифметике, которую нельзя ни доказать, ни опровергнуть." - это абсолютно точное утверждение, являющееся частным случаем теоремы, которого мне достаточно, чтобы опровергнуть ваше якобы доказательство.
Остальное фуфло от дипсика разбирать лень. Всего хорошего.
Ваша статья про первую теорему Геделя о неполноте демонстрирует, что вы не поняли даже формулировку этой теоремы.
Гедель утверждает существование формулы в арифметике, которую нельзя ни доказать, ни опровергнуть.
А у вас арифметика превратилась в "любую непротиворечивую систему утверждений" - с этим и сам Гедель не согласен в свой теореме о полноте классической логики, в которой множество тавтологий вообще-то тоже - непротиворечивая система утверждений.
И еще "невозможность опровергнуть" с какого-то перепугу превратилась в "правдивость". Для справедливости такой замены сначала надо доказать полноту. Вот для классической логики эту полноту Гедель доказал, там можно ставить знак равенства между неопровержимостью и истинностью. А в арифметике - нельзя. Тоже Гедель доказал.
Поэтому опровергаете вы там что угодно, но не теорему Геделя.
По-моему опыту, на первое место надо ставить здравый смысл. А метрики и разные аббревиатуры нужны только, чтобы убедиться, что здравый смысл не зарулил куда-то не туда.
От подобных неприятных сюрпризов защищает очень простой прием: всегда моделируйте потоки данных. Даже если это монолит, поток данных между сервером приложений и БД нуждается в контроле не меньше, чем между клиентом и сервером приложений. Если вы сначала проектируете API и только потом его реализуете, то вся необходимая информация должна быть уже на этапе проекта: берем каждую точку внешнего API; отслеживаем полный граф вызовов для выполнения запроса к этой точке; честно отвечаем себе, является ли этот граф разумным.
Если вы работаете в конторе, где менеджмент предпочитает метрики здравому смыслу, этот прием можно упаковать во что-нибудь типа "длина типичного (кратчайшего, наихудшего) пути выполнения запроса", который считать для каждого типа запроса по количеству пересечений границ сервисов, совершаемых потоками данных по пути от начала запроса до отправки ответа. Какое значение этой метрики считать хорошим не скажу, сильно зависит и от решаемой задачи, и от условий, в которых она решается. И, разумеется, ее надо не минимизировать (так вы можете прийти только к монолиту), а выставить верхний порог, превышение которого будет сигнализировать о подозрительности архитектуры.
Ну то есть вы не хотите взять на себя труд пояснить для меня сделанное вами утверждение? В такой ситуации я не вижу причин брать на себя труд пояснять что-то для вас.
А вообще, не очень понимаю этот Ваш комментарий. Я даю конструктивное предложение, как улучшить форму подачи Ваших идей для читателя, а Вы мне приветы передаете.
Спасибо, им от меня тоже привет. В последнем, к слову, Ваша идея о неизменности состояния тоже демонстрируется нагляднее, чем в Bogus:
В JS декларации (const, let, function и т.д.) не менее важны, чем присваивание (=), на которое Вы сослались.
Т.е. Вы решили для демонстрации функционального стиля придумать оператор ":=", который у людей ассоциируется в первую очередь с присваиванием в процедурных языках? Ну ОК. Хотя, на мой взгляд, вопросов было бы меньше, если бы Вы использовали синтаксис какого-нибудь существующего языка или хотя бы использовали разные обозначения для оператора присваивания значения переменной и оператора именования выражения. Например, так:
А все-таки, что это за язык?
Вы утверждаете, что после устранения сахара (записи вызова метода в синтаксической форме инфиксного оператора) сахара стала больше. Позвольте поинтересоваться, что Вы считаете сахаром, что - сахарным песком? И как их отличаете от "безуглеводного" кода?
Там конечно надо смотреть исходники, вероятно, какой-нибудь Scala, где, скорее всего, после устранения сахара, окажется что-то вроде:
next( prev ).assign(prev.plus(one))Буквально: ":=" - это метод объекта, который вернуло выражение next( prev ). А "+" - это метод объекта prev. Обеспечению типобезопасности тут синтаксис никак не мешает. Нужно всего лишь смириться, что привычные символы могут означать что-то очень необычное, просто потому, что так решил автор конкретного метода "+".
Свои проекты публично показать не могу, поэтому, если Вы действительно хотите поделиться своими идеями с сообществом, можете показать свой пример реализации Контейнера Объектов. У Вас, как я понял, все лежит в публичных репозиториях? Можно просто накидать ссылок, где какие части реализации смотреть, на что стоит обратить особое внимание, и т.д.
Тут, похоже, я неточно выразился. Я не призываю описывать недостатки JS. Но мы все знаем, что типизация в js - это едва ли не самое критикуемое из слабых мест языка. А из принципов, на которых должна строиться разработка, трудно извлечь конкретику, как же этот недостаток может быть преодолен. Этому внимание уделено весьма вскользь: JSDoc, контракты. Причем в размытых формулировках, из которых лично мне было мало что понятно, пока Вы не добавили уточнений в комментариях.
Тут логика очень простая: вот я, например, тоже фуллстек и тоже пишу на js. Относительно небольшие проекты я совершенно точно буду писать на js. А большие, где сделать качественный code review в одно лицо уже точно не получится (для меня это примерно 10 тысяч сущностей, у Вас может быть больше, но где-то этот порог все равно есть), сопряжены с компромиссами, болью и костылями. Может я такие проекты просто не умею готовить? Возможно. Но и в предложенной статье рецепта приготовления я не увидел. И будь в ограничениях к принципам сказано что-то еще про размер проектов, на которых это работает - придраться, пожалуй, было бы не к чему.