• Имитация Сложности — Антиномия Простого и Сложного
    +1

    Интересная тема, спасибо. В общем чуть более чем полностью согласен. Моё скромное мнение заключается в том, что сложность бывает двух типов: естественная сложность автоматизируемого бизнес процесса и искусственная сложность привнесенных абстракций, фоеймверков и прочего, прочего, прочего. Задача проектирования — реализовать естественную сложность в некотором управляемом виде при этом, по возможности, не привнести искусственную сложность. Эту идею можно выразить в простом ритуале — каждый раз добавляя в дизайн приложения новый элимент, нужно спросить себя позволяет ли этот элемент упростить работу с бизнес логикой и если да, то можно ли добиться этого же результата проще? Конечно бывают крайние случаи, когда нам нужно выживать под нагрузкой например. Но тем не менее.


    И не много критики.


    Про Дашу и бизнес логику. Тут есть обратная сторона в картинке. 80% стека вызовов это фреймверк, то есть общий код, который ты по идее не должен трогать совсем. А вот бизнес логика это 20% которые должны быть довольно простые. Если отказаться от этих 80%, то придётся добавить к бизнес логике ручную работу с транзакциями, безопасность, работу с бд. Не факт, что получится проще.


    Ну и ещё один момент. Простые решения требуют непрерывного рефакторинга. В случае, если мы написали код в методе контроллера и наше приложение осталось простым, то мы выиграли, сэкономили кучу времени. Но если приложение начало расти? Где та грань, когда нужно начинать переходить от простых решений к сложными? Когда контроллера два? Когда их 10? Проблема в том, что обычно тебя просят дописать один метод, потом второй. И каждый раз ты думаешь, что это всего то ещё одна фича, ничего страшного. А потом приходится в какой-то момент рефакторить монстра из лапши на тысячи строк кода. Собственно по этому часто и делают оверинжиниринг на будущее, потому что боятся, что потом не будет времени на рефакторинг и надо брать это время пока дают. Не сказал бы, что это хорошо. Лучше когда на каждую фичу закладывается время на рефакторинг, тогда можно идти от простых решений к сложными по необходимости и без проектирования на будущее.

  • Прекрасное настоящее и светлое будущее Scala
    0
    вы вводите в заблуждение людей. так бы сразу и писали, что мол на тот момент CLR поддерживать было не оправданно, так как работал CLR только под Win.
  • Прекрасное настоящее и светлое будущее Scala
    +1
    "- JVM работает под виндой, непонятно зачем нужен тогда CLR, который ни под чем другим не запускается."

    вы отстали от жизни, CLR теперь запускается на всех основных платформах. )
  • Прекрасное настоящее и светлое будущее Scala
    –1
    скорость компиляции, «объем» рантайма(привет Андроид), сложность освоения и внедрения в конкретной команде
  • Прекрасное настоящее и светлое будущее Scala
    –2
    звучит здорово, надеюсь все получится, а пока котлин выглядит привлекательней.
  • Microsoft открыла исходный код PowerShell
    +2
    скорее наконец разрешила dotnet разработчикам работать с линукса
  • Как я повысил продуктивность с помощью стриминга
    0
    посмотреть как другие люди готовят свои проекты, какую архитектуру используют, посоветовать и обсудить свои решения. а еще очень полезно когда изучаешь новый язык, например с С++ перешел на python, а там немного другой подход к разработке и проектированию, другие стандарты кодирования, другая философия, лучшей способ в данном случае быстро понять как принято писать в сообществе, это посмотреть стрим уже опытного разработчика на python.
  • Как я повысил продуктивность с помощью стриминга
    0
    при таком сценарии продуктивность может упасть, ты вроде как постоянно отвлекаешься на вопросы в чате.
  • «ИТ-кочевники»: почему компании до сих пор принимают на работу саботажников
    0
    А я и задаю эти самые вопросы на собеседование, в результате поиск сотрудников на вакантное место затягивается на месяцы(прошлый раз 4ре), да вот только работы в этим месяцы меньше не становится. А если нужен специалист с нераспространенными компетенциями, то поиски могут окончится ничем(по крайней мере в условиях ограниченного бюджета). Поэтому я и написал, что вопрос стоит довольно остро.
  • «ИТ-кочевники»: почему компании до сих пор принимают на работу саботажников
    +5
    Очень спорные мысли озвучены.

    Во первых, что значит потребительское отношение и почему это плохо? Я работник, мне платят деньги, я решаю задачи, моя выгода работать меньше \ над интересными проектами, а получать денег больше. Я работодатель, я плачу работнику деньги за решенные задачи, моя выгода получить решенных задач больше \ решения качественней, а заплатить денег меньше. Мне кажется тут правила ясны, потребительское отношение с двух сторон. В идеальной ситуации можно прийти к компромиссу.

    Второй момент, перебежки сотрудников, джунов. Может дело действительно в компании? Я бы даже осмелился предположить, что в специфики наших ИТ-компаний. Кейс из личного опыта. Пришел я джуном в компанию Х, компания большая, известная, не гос. сектор, а там ни баг-трекера, контроль версий древний и больше мешает, процесса четкого нет, тестов нет, архитектуры никакой нет, в общем классическая хаотичная разработка. Через кучу нервов, споров и перемогание сопротивления коллеги и руководства удалось внедрить Youtrack + TeamCity + Mercurial, написать тесты, поднять свой nuget-сервер и навести порядок в коде и архитектуре(хвалится этим конечно нельзя было, но уже можно было смотреть без слез). Всем в конечном итоге все понравилось, продуктивность команды повысилась, но спасибо никто не сказал. Через пару лет история повторилась только в компании Y, опять кучу нервов и сопротивления, спасибо никто не сказал. Сейчас я поумнел и ищу работодателя, который сам понимает важность налаженного процесса разработки. Супергероем который всех спасает вопреки их желанию быть больше не желаю, идет 2016 все же. Так вот, может перебежки сотрудников обусловлены не их негативными качествами, а проблемами в компаниях? Тем более, что джуны еще не обладают достаточным опытом, чтобы сформулировать и задать нужные вопросы, которые помогут понять, как на самом деле обстоят дела.

    PS: на самом деле я не отрицаю обозначенные в статье проблемы, довольно много провожу собеседований, сейчас руковожу командой разработчиков, насмотрелся всякого. Проблема не добросовестных, не компетентных, не мотивированных соискателей \ сотрудников имеет место быть и стоит довольно остро. Просто считаю, что ситуацию стоит рассматривать комплексно, с разных углов.
  • ReactOS 0.4.2 будет превосходным
    0
    Очень интересный момент, кстати. А как дела обстоят с dotnet core? Я так полагаю, там нет подобных ограничений, ведь он вроде как кроссплатформенный и должен запускаться в числе прочих на linux, может тогда стоит сразу ориентироваться на него?
  • .NET Core: релиза не будет, но вы держитесь, здоровья вам, хорошего настроения
    +3
    Я не уверен, что модульность так уж нужна, это может породить проблемы — кучу пакетов реализующих одно и тоже из ныне стандартной библиотеки, ад зависимостей как следствие. Конечно для мобильных платформ и микроконтроллеров это плюс, можно поставлять и разворачивать только нужное и экономить место, но есть мнение, что память дешевле программистов. Но пока рано судить, посмотрим что будет в релизе, попадет ли туда mscorelib и самое главное в каком виде.

    Я так понимаю, что основная идея core это возможность устанавливать рантаймы и упаковывать их вместе с приложениями, то есть более платформа не прибита гвоздями к ОС и стала достаточно легковесной. Это большой шаг, отсюда и новое название, хотя конечно вся эта история с переименованием очень путает.

    Если смотреть какими темпами меняется api, устаревание во время разработки тут явно не грозит. ) Но в целом да, уж очень не терпится.
  • .NET Core: релиза не будет, но вы держитесь, здоровья вам, хорошего настроения
    +12
    Вообще сейчас очень ответственный этап, излишняя спешка может оказаться фатальной в будущем. Так что как по мне, пусть уж лучше выпустят релиз через год или два, чем налажают. Споры и дебаты в такой период нормальны, даже некоторая доля хаоса и анархии, никто же не знает как будет идеально, вот и пытаются общим умом и через RCxxx выяснить.К слову большая часть изменений в RC2 мне нравится, я думаю что идут в правильном направлении.
  • CoLaboratory: Rust — поговорим о Rust в «Лаборатории Касперского» 17 мая
    0
    очень интересно. подскажите, планируется ли видео или трансляция для иногородних?
  • Простой инструмент SQL Server Tool на C#
    0
    В общем полностью согласен, но ИМХО думаю, что не на python, а на PowerShell, все же PS есть на любом виндовом сервере, все средства из коробки, нет необходимости ставить python
  • Ключевое слово «var» в Java: пожалуйста, только не это
    +2
    проходили уже все это в C#, тоже было много гнева и воплей как появился var, но потом все привыкли, оказалось удобно. мое субъективное мнение, в том, что вывод типов рулит и чем меньше мне их придется писать явно руками, тем лучше.
  • В пятницу судьба Джулиана Ассанджа будет решена
    0
    Ну это как публичное одобрение или порицание мировым сообществом. Есть мнение, что во время суда это решение может оказать давление на судей и присяжных, что в итоге закончится оправдательным приговором.
  • Поднимающийся компьютерный стол для дома, немного industrial-style
    0
    выглядит интересно, но есть два вопроса:
    1. если не секрет, то сколько в сумме было затрачено времени и денег на производство?
    2. проводились ли испытания надежности конструкции? выдержит ли два монитора + кронштейны + ноутбук и если я еще и обопрусь на столешницу вдобавок?