Создайте почтовый ящик/аккаунт/бота куда можно линки посылать. После премодерации добавлять в канал. Тогда можно будет аудитории интересными статьями делиться.
Если вы более менее все статьи просматриваете, то можно сделать несколько дочерних каналов (типа Amazing .NET Junior, Amazing .NET Tutorials, Amazing .NET The Best, Amazing .NET News, Amazing .NET Libraries и т.п.) и после просмотра из основного канала раскидовать по дочерним, некоторым интересны специфичные категории статей, а лента основного канала может быть перегруженной.
Или сделать админку/бота для этих функций и делегировать группе модераторов из числа доверенных товарищей.
Можно добавить https://dev.to/t/csharp , но там без премодерации не обойтись, по рейтингу там нельзя правильно судить о качестве материала. Хороший может быть вообще без лайков, а хлам может быть поднят до небес.
Ну и конечно создать подобные каналы для других языков, типа TypeScript, если вся инфраструктура уже есть и затраты на добавление новых языков минимальны.
В этом один из плюсов подобного подхода, когда из кусков собирается целое, а не реализуется честное множественное наследование. В результате получается стандартный класс и при наличии проблем, он упадёт при компиляции, а не будет пытаться разрулить дополнительными правилами.
Сейчас так и делаю, смотрю кто решал те или иные проблемы на github, развивается ли проект и т.д. и внедряю по возможности.
Очень часто такое приводит к эффекту «leftpad-a».
Когда в проект добавляется миллиард зависимостей из-за самых простейших вещей. Особенно с .net core это очень заметно, становится похожим на nodejs.
Сложно отслеживать зависимости, качество и безопасность этих проектов.
Недавно обсуждали с коллегами идею сделать nuget для исходников, т.е. проекты меньше определённого размера тянуть не бинарниками, а исходниками. И публиковать их в формате, чтобы можно было брать нужные части, а не «all or nothing». Т.е. ты становишься владельцем симпортированного кода и отвечаешь за него.
Ну не знаю, мне вот в бизнес интересней вникать, чем в очередную новомодную библиотеку.
Все люди разные, я например повникал достаточно, чтобы бросить менеджерство и обратно разработкой заняться.
Но всё равно постоянно пытаются навесить сверху. Какое-то проклятие профессии, как будто в свой области мало сложности.
Спасибо за обосование, поговорю с коллегами, скорее всего прикрутим.
И исключение более правильный подход, чтобы в случае если протекло что-то, где-то то гораздо правильнее выбросить исключение, чем возвращать нечто, не ожидаемое принимающей стороной.
Я с ужасом жду каждой новой фичи языка, потому что уже знаю, что первое же для чего она будет использована, это создание содома и гомморы.
Ну когда что-то новое появляется, начинают экпериментировать и конечно могут от энтузиазма немного переборщить.
Экпериментировать конечно лучше на маленьких проектах, но я вполне себе допускаю что писатели из вашего примера, не считали своё изделие «содомом и гомморой» — потому что это была их «содома и гоммора», также как очень вероятно, что новый человек пришедший на ваш проект, потихоньку, за глаза рассакзывает какой-же «содом и гоммору» творит fkthat, а вы искренне гордитесь выбраному подходу, потому что это ваш «содом и гоммора».
Приватные методы/свойства нельзя объявить абстрактными, для protected конечно можно.
Мы думали над подобным, но решили что явное объявление более правильный подход, чем подразумеваемое правило. Немного более многословный, но лично я бы предпочёл так. Хотя конечно можно обе версии добавить. т.е. игнорировать и abstract в дополнение к TraitIgnore.
Вот второй случай я и считаю самым неудачным для проекта в целом.
Я может быть скажу крамольную мысль, но не все разработчики заботятся о том что «лучше» для проекта, особенно если проект сам по себе унылое г. И придумывают себе немного развлечений в виде написания инструментария, велосипедов и т.п.
Тем более что «лучше» для проекта — оно у всех разное, не дай бог ещё бизнес спросить, что же лучше, много нового для себя можно открыть.
Это очень мощный инструмент, неправильное применение которого на стадии экспериментов может превратить в будущем проекты в совершенно не поддерживаемое легаси.
Опять же, не понятно какое у вас предложение? Запретить и не пущать? Понятно что будут рождены уродливые мутанты (вполне возможно что и этот проект один из них), но это как раз вполне ожидаемо.
да я бы предпочел в будущем проекты, которые используют стандартные и широко зарекомендованные приемы, чем велосипеды
Ну тогда надо ещё пообещать самому не баловаться, а использовать только «стандартные и широко зарекомендованные приемы».
Полностью согласен, поддерживать чужой велосипед, не большое удовольствие. Вот писать свой — другое дело.
Но честно говоря не очень понятно за что вы голосуете — писать всё на чистом C#? Или использовать только широко распространнёные библиотеки? До того как они стали широкораспространнёными, тоже делали MVP и смотрели — взлетит идея или нет. Не сразу же все знаменитыми становились, ну или по крайней мере у них был бюджет, чтобы потратить на развитие.
А source generators сейчас как раз в идеальной стадии для экспериментов, попробовать что может получиться. Хорошие идеи приживутся, плохие отсеются.
Всё гораздо более тривиально чем кажется — круды, много крудов, очень много крудов. В определённый момент начинается дежавю, что всё уже где-то было сделано и хотелось бы проехаться на уже реализованных фичах.
Недавно была хорошая статья прямо не касающаяся конкретно программирования, но там есть очень правильная идея «рычага».
Так вот как раз трансформация кода (и AOP как его часть) и автогенерация кода дают тебе этот рычаг. Существует некий порог входа, но когда плечо рычага достигнет опередлённого уровня, тогда появляется новое качество. Опять же работает это не на всех проектах и надо затратить некоторые усилия, но с правильным инструментом это вполне посильно.
Я сильно надеюсь что в конце концов спецификации языка и IDE будут включать подобную поддержку из коробки, ну а пока каждый д… т как он хочет.
Стиль, с которым я согласен больше всего (но ленюсь следовать)
А IDE (если вы пользуетесь idea + intellij-haskell) не позволяет заставлять вас следовать определённому стилю или по крайней мере помогать в приведении к выбранному формату.
Согласен по поводу чтения, но надо вероятность возникновения такого события учитывать, неудобство человека который раз в полгода что-то посмотрит, с учётом того что он и так язык не знает и ему придётся детально разбираться, может не стоить выгод приобретаемой основной командой.
И вот тут-то и окажется, что документация должна быть first class citizen
В теории да, но на как говорят
В теории, разницы между теорией и практикой не должно быть. Но на практике ...
Есть объектвиная реальность данная нам в ощущения и документация там «illegal immigrant» по вашей терминологии.
Читателю будет легче, если у интерфейса будет префикс. Точка.
Моя точка зрения, что надо следовать принятым практикам, чтобы завтра пришёл новый боец и с достаточной вероятностью он уже знает что, как и где. Для c# это значит префикс «I» перед интерфейсом и префикс «T» перед дженериками. Даже если лично моё чувство прекрасного страдает.
Если же в хаскеле не принято ставить префиксы (не знаю так это или нет), то лучше не надо, даже если сильно хочется.
Судя по вашим комментариям и статьям, вы вполне себе необычный случай (в хорошем смысле) и некоторые практики которые обязательны для простых смертных в вашем случае могут быть неприменимы или даже вредны.
Есть такая концепция как intelligence amplification — в самом простом случае можно сравнить эффективность решения математических задач в уме vs человеком у которого есть листок бумаги и ручка. Вполне допускаю что существуют те кто в уме будут более эффективно решать, но в целом бумага плюс ручка дают существенную фору.
Также и IDE, правильная IDE является очень эффективным усилителем как качества так и производительности _обычного_ программиста. Даже плагины к ней могут играть существенную роль (VisualStudio vs VisualStudio+ReSharper).
Конкретно в параметрах метода так делать нельзя, в вашем примере будет ошибка компиляции.
Ну и сделано это для удобства использования при автогенерации кода, ненужны специальные подпрыгивания, чтобы отслеживать когда надо её ставить, а когда нет.
Когда захожу из браузера без русской локали, в 80% случаев вижу пустой экран (сегодня приятное исключение, одна статья есть)
Потому что по умолчанию сделано как и в русской версии — «top» -> «day»
Но очень часто нету заплюсованных английских статей и висит сообщение «no articles»
Хотя если переключиться в «all posts» там будут статьи, даже за текущий день.
Так что если вы хотите привлекать англоязычную аудиторию, было бы логично показывать «all posts» по умолчанию, пока не достигните какого-то потока наполняемости.
А то приходит англоязычный посетитель на главную, там висит «no posts» или одинокая статейка, он разворачивается и больше не ходит на хабр. Зачем ему разбираться в том как у вас сделано и что надо жать на «all posts», надо чтобы по умолчанию всё было правильно сделано.
Я свою статью перевёл, а получается что толку мало. В том числе и из-за подобной логики.
Создайте почтовый ящик/аккаунт/бота куда можно линки посылать. После премодерации добавлять в канал. Тогда можно будет аудитории интересными статьями делиться.
Если вы более менее все статьи просматриваете, то можно сделать несколько дочерних каналов (типа Amazing .NET Junior, Amazing .NET Tutorials, Amazing .NET The Best, Amazing .NET News, Amazing .NET Libraries и т.п.) и после просмотра из основного канала раскидовать по дочерним, некоторым интересны специфичные категории статей, а лента основного канала может быть перегруженной.
Или сделать админку/бота для этих функций и делегировать группе модераторов из числа доверенных товарищей.
Можно добавить https://dev.to/t/csharp , но там без премодерации не обойтись, по рейтингу там нельзя правильно судить о качестве материала. Хороший может быть вообще без лайков, а хлам может быть поднят до небес.
Ну и конечно создать подобные каналы для других языков, типа TypeScript, если вся инфраструктура уже есть и затраты на добавление новых языков минимальны.
Когда в проект добавляется миллиард зависимостей из-за самых простейших вещей. Особенно с .net core это очень заметно, становится похожим на nodejs.
Сложно отслеживать зависимости, качество и безопасность этих проектов.
Недавно обсуждали с коллегами идею сделать nuget для исходников, т.е. проекты меньше определённого размера тянуть не бинарниками, а исходниками. И публиковать их в формате, чтобы можно было брать нужные части, а не «all or nothing». Т.е. ты становишься владельцем симпортированного кода и отвечаешь за него.
Все люди разные, я например повникал достаточно, чтобы бросить менеджерство и обратно разработкой заняться.
Но всё равно постоянно пытаются навесить сверху. Какое-то проклятие профессии, как будто в свой области мало сложности.
И исключение более правильный подход, чтобы в случае если протекло что-то, где-то то гораздо правильнее выбросить исключение, чем возвращать нечто, не ожидаемое принимающей стороной.
Экпериментировать конечно лучше на маленьких проектах, но я вполне себе допускаю что писатели из вашего примера, не считали своё изделие «содомом и гомморой» — потому что это была их «содома и гоммора», также как очень вероятно, что новый человек пришедший на ваш проект, потихоньку, за глаза рассакзывает какой-же «содом и гоммору» творит fkthat, а вы искренне гордитесь выбраному подходу, потому что это ваш «содом и гоммора».
Мы думали над подобным, но решили что явное объявление более правильный подход, чем подразумеваемое правило. Немного более многословный, но лично я бы предпочёл так. Хотя конечно можно обе версии добавить. т.е. игнорировать и abstract в дополнение к TraitIgnore.
Тем более что «лучше» для проекта — оно у всех разное, не дай бог ещё бизнес спросить, что же лучше, много нового для себя можно открыть.
Опять же, не понятно какое у вас предложение? Запретить и не пущать? Понятно что будут рождены уродливые мутанты (вполне возможно что и этот проект один из них), но это как раз вполне ожидаемо.
Ну тогда надо ещё пообещать самому не баловаться, а использовать только «стандартные и широко зарекомендованные приемы».
boooring…
Но честно говоря не очень понятно за что вы голосуете — писать всё на чистом C#? Или использовать только широко распространнёные библиотеки? До того как они стали широкораспространнёными, тоже делали MVP и смотрели — взлетит идея или нет. Не сразу же все знаменитыми становились, ну или по крайней мере у них был бюджет, чтобы потратить на развитие.
А source generators сейчас как раз в идеальной стадии для экспериментов, попробовать что может получиться. Хорошие идеи приживутся, плохие отсеются.
Для x10 «we have to go deeper», искать рычаг подлиньше. Ну или изначально быть талантливым.
Так вот как раз трансформация кода (и AOP как его часть) и автогенерация кода дают тебе этот рычаг. Существует некий порог входа, но когда плечо рычага достигнет опередлённого уровня, тогда появляется новое качество. Опять же работает это не на всех проектах и надо затратить некоторые усилия, но с правильным инструментом это вполне посильно.
Я сильно надеюсь что в конце концов спецификации языка и IDE будут включать подобную поддержку из коробки, ну а пока каждый д… т как он хочет.
В теории да, но на как говорят
Есть объектвиная реальность данная нам в ощущения и документация там «illegal immigrant» по вашей терминологии.
Моя точка зрения, что надо следовать принятым практикам, чтобы завтра пришёл новый боец и с достаточной вероятностью он уже знает что, как и где. Для c# это значит префикс «I» перед интерфейсом и префикс «T» перед дженериками. Даже если лично моё чувство прекрасного страдает.
Если же в хаскеле не принято ставить префиксы (не знаю так это или нет), то лучше не надо, даже если сильно хочется.
Есть такая концепция как intelligence amplification — в самом простом случае можно сравнить эффективность решения математических задач в уме vs человеком у которого есть листок бумаги и ручка. Вполне допускаю что существуют те кто в уме будут более эффективно решать, но в целом бумага плюс ручка дают существенную фору.
Также и IDE, правильная IDE является очень эффективным усилителем как качества так и производительности _обычного_ программиста. Даже плагины к ней могут играть существенную роль (VisualStudio vs VisualStudio+ReSharper).
Ну и сделано это для удобства использования при автогенерации кода, ненужны специальные подпрыгивания, чтобы отслеживать когда надо её ставить, а когда нет.
Думаю что это отталкивает, хотя видно что три статьи на анлийском сегодня есть, одна даже от PVS-Studio.
Проверить очень просто на https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fhabr.com&tab=desktop, там будет скриншот того как видно главную страницу по умолчанию.
Потому что по умолчанию сделано как и в русской версии — «top» -> «day»
Но очень часто нету заплюсованных английских статей и висит сообщение «no articles»
Хотя если переключиться в «all posts» там будут статьи, даже за текущий день.
Так что если вы хотите привлекать англоязычную аудиторию, было бы логично показывать «all posts» по умолчанию, пока не достигните какого-то потока наполняемости.
А то приходит англоязычный посетитель на главную, там висит «no posts» или одинокая статейка, он разворачивается и больше не ходит на хабр. Зачем ему разбираться в том как у вас сделано и что надо жать на «all posts», надо чтобы по умолчанию всё было правильно сделано.
Я свою статью перевёл, а получается что толку мало. В том числе и из-за подобной логики.