• Коварный вопрос по Event \ Delegate
    0
    DoWork(null, EventArgs.Empty) при объявленном эвенте работать вне класса не будет — я это имел в виду.
  • Коварный вопрос по Event \ Delegate
    0
    Нет, не Евгения. Слушай, а че ты мне не ответил в личке? Такое ощущение, что испугался жутко6)
  • Коварный вопрос по Event \ Delegate
    0
    да, ты прав.
  • Коварный вопрос по Event \ Delegate
    +4
    >a.DoWork += AfterSomeWork;
    >и как вы думаете, что скажет компилятор

    А что мне думать? :) Я знаю. Компилятор ничего не скажет. Вставьте в студию и проверьте. Спасибо за совет — читаю регулярно.
  • Коварный вопрос по Event \ Delegate
    –1
    Это аспект, реализующий отличие номер 2) про ограничение возможностей доступа к делегату. Danov прав.
  • Мой Круг помогает составить резюме
    +1
    Не легче ли в этом случае свое резюме нафигачить, безо всяких моихкругов?:)
  • Мой Круг помогает составить резюме
    0
    Дык а нафига его редактировать, если он в моем круге редактируется?:) типа, и там и там чтобы редактировать можно было?:)
  • Мой Круг помогает составить резюме
    +1
    Почему ворд, а не pdf?:)
  • Канбан в IT (Kanban Development)
    0
    Картинки там переведены.

    В книжке рассмотрены приводимые вами ситуации. Вы бы почитали сначала, а потом умничали.
  • Канбан в IT (Kanban Development)
    0
    В общем, я вам объяснять не буду, вы просто не совсем четко понимаете, как это все работает.

    Вам следует прочитать вот эту книгу:
    scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf

    Там всего 100 страниц и все на русском. Не поленитесь, это очень полезно.
  • Канбан в IT (Kanban Development)
    0
    Что-то вы усложняете. Какая еще средняя температура по больнице? Есть спринт в днях, есть задачи, есть их оценка в идеальных днях. Устанавливаете фокус-фактор, умножаете и отрезаете те задачи, которые не вмещаются в спринт. Если сделали все задачи — угадали с фокус-фактором, не сделали — значит, фокус фактор был ниже и на следующий спринт его надо скорректировать. Сделали больше — круто, значит, фокус-фактор на следующий спринт можно как-то увеличить.

    Здесь квалификация отдельного человека не причем, идет оценка работы всей команды как единого целого.
  • Канбан в IT (Kanban Development)
    0
    >Ну, если менеджер — обезьяна, то тут и скрам не поможет.
    Именно что поможет. Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.

    >Что вы знаете про весь проект с этими данными?
    Зависит от срока и размера проекта. Если проект мелкий — средний, то всю картину можно разбить на бизнес-задачи. Если он очень большой (как у нас сейчас, например), то берется некоторый актуальный зазор задач, определяемый на встречах с заказчиком — своего рода «мелкий» проект, без особых четко очерченных границ. В любом случае, я хочу сказать, что «знать» про проект — можно. Составление бэклога с последующей приоретизацией и межкомандным согласованием — это очень важная задача. Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.

    >когда надо, а что не успели — отрезать.
    Вы знаете, получается что в канбане так — ВДРУГ всем стало ясно, что не успели. Работали работали, и не успели.
    Итерация дает обратную связь, позволяет изменять процесс и делать его прозрачным.

    >Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.

    Вот этого я не понимаю. Спринт закончился — если остались задачи, спринт провалился, устраивается разбор полетов. В канбане задача может провисеть мертвой некоторое время, пока кто-нибудь не спохватится — «ой, что это у нас тут».

    >и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну
    По-моему, это некорректно. Задачи ведь неравномерны по времени своего исполнения!

    >Если оно растет — что-то не так.
    В статье писалось, что такого аспекта как замеры времени в процессе не существует:)))

    Ладно, хватит придирок. Дело в том, что если сравнивать скрам с канбаном, если вы признаете последний набором методик, а не процессом разработки, некорректно. Если же брать канбан как процесс в том виде, в котором он приведен в статье — то канбан нежизнеспособен в жестких условиях поставки.
  • Канбан в IT (Kanban Development)
    +1
    Статья поначалу вызывает, восторг, да. Пока думать не начинаешь:) Почитайте комменты оппонентов.
  • Канбан в IT (Kanban Development)
    +3
    Что вы говорите. Одно из понятий скрама — фокус-фактор, который говорит, как эффективно работает команда и сколько она способна решить задач за квант! Квант здесь — измеримое понятие, т.е. бизнес-людям можно оценить сверху, будут ли реализованы все важные запланированные задачи к сроку поставки, или же нужно сокращать функционал.

    В канбане я этого не вижу. Т.е. с первого взгляда — это такая текучка, очень хорошая для постоянного процесса (как непрерывное производство машин, например), но для производства ПО — это как-то оооооочень гибко.

    Раз уж решили сравнивать скрам, то я вот что скажу — скрам хорош тем, что он защищает разработчиков от оголтелого произвола менеджеров, или же наоборот, позволяет менеджерам видеть, кто саботажник или просто плохо работает. Это позволяет скорректировать планы и той, и другой стороне.

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

    В канбане нет фокус фактора, весь процесс производства — постоянная текучка, стало быть менеджер будет скакать вокруг меня и орать, чтобы мы работали быстрее, будет пытаться впихнуть больше задач единовременно или увеличить емкость семафора с задачами. Говорить ему при этом «Дядя, че ты ко мне лезешь, неужели ты не знаешь, что от тебя в разработке проекта ничего не зависит?», как было заявлено в статье, это моветон, меня дядя в 24 часа уволит за некомпетентность.
  • Рефакторинг: миссия (не)выполнима?
    0
    жалко вы весь.нет у себя свернули. что-то у меня вся программерская жизнь рядом с вами :)
  • Рефакторинг: миссия (не)выполнима?
    +3
    Вот тут все Фаулера рекомендуют, а я порекомендую Макконнела :)

    Больше всего мне понравилась методика «чистый идеальный мир» — интерфейс — «ад», где он рекомендует определить интерфейс между грязным кодом и чистым идеальным кодом, и потихоньку переносить грязный код за «барьер».

    Ну и вообще, цитата из книжки:
    Значение слова «рефакторинг» довольно размыто: так называют исправление дефектов, реализацию новой функциональности, модификацию проекта — по сути любое изменение кода. Это неуместно. Целенаправленный процесс изменений может быть эффективной стратегией, обеспечивающей постепенное повышение качества программы при ее сопровождении и предотвращающей всем известную смертельную спираль энтропии ПО, но само по себе изменение достоинств не имеет.
  • Рефакторинг: миссия (не)выполнима?
    0
    а вы в сикужи работаете?:)
  • Раритетный клон atari 2600
    0
    А не знаете, есть порт? Я бы поиграл, как щас помню — мне восемь лет тогда было, когда в нее гонял
  • Layers + Unity Container
    0
    Че-то не ушел мой комент. Отвечу еще раз.

    1) Строить объекты доменной логики через фабрику-контейнер — практически моветон, месье. Практически — это потому, что оно моветон за исключением случая, когда доменные объекты строятся и наполняются данными через фабрику (как DTO объекты). В этом случае доменные объекты должны иметь публичные интерфейсы и, по всей видимости, должны быть read-only, чтобы можно было защититься от нарушения целостности данных. Еще минус в том, что вы должны явно следить за жизненным циклом создаваемых доменных объектов — удалять их из контейнера и диспоузить по требованию.

    2) У меня в примере класс-модуль не инъецируется. Вы путаете с composite application library, там бутстраппер действительно делает инъекцию в модуль, а я всего лишь создаю это класс и вызываю его метод.

    Понимаю ваши опасения в плане явного задания свойств-зависимостей. Для этого их нужно делать пабликами, что не всегда верно с точки зрения инкапсуляции. Делайте микросервисную архитектуру, где сервисы или нужные вам объекты инъектятся через конструктор.

    Ну и вообще еще совет — используйте контейнер и инъектор как можно реже и только там, где он действительно нужен. Контейнер сам по себе представляет расшаренный ресурс между всеми участками кода, которые с ним работают. Через это нарушается концептуальная целостность и опять же, инкапсуляция, потому что работающие участки кода должны знать, что лежит в контейнере и в каком состоянии он находится, дабы не нарушить свою работоспособность.
  • Layers + Unity Container
    0
    Вот бляха, и правда из-за этой галки пост в ленту не попал.

    Дело в том, что тебе каждый умник скажет, что да, разделить на слои это круто. Все аналитики тебе будут писать документы, где система будет разделена на слои, но вот о том, каким образом и как разработчики будут эти слои делать — сие неведомо.

    Вот мы на своем проекте все в жопу запороли, хотя да, «слои» есть:)
  • Layers + Unity Container
    +1
    Да вы знаете, здесь дело не в тех терминах, которые вы написали. Здесь дело в практической применимости. Все вышесказанное можно написать без Unity, на ServiceContainer например. Просто, кода будет немножко больше.
  • Layers + Unity Container
    0
    Ну и как, понял границы?:)
  • Layers + Unity Container
    0
    Устал, сори. Открыл всем. Но теперь уже в ленту не попадет, да?
  • DI и IoC для начинающих, часть 2
    –1
    :))) этапять
  • DI и IoC для начинающих
    +1
    >Вопрос такой, в какой системе IoC контейнер может быть полезен при разработке бизнес приложений и на бою?

    самое простое решение — архитектура черных ящиков, или «черных слоев», когда при пуске приложения контейнер проходит по всем слоям и регистрирует задаваемые слоями реализации. При этом в сборке реализацию можно скрыть от лишних глаз, т.е. добиться полной инкапсуляции в слое. А это очень круто.

    >Чем IoC лучше?
    Да ничем он не лучше. Это просто паттерн автоматического определения зависимостей. Он есть в контейнере Unity. Контейнер Юнити описывается автором только потому, что это типа «модное и современное» решение, хотя, судя по ответам на технические вопросы, автор только-только что-то прочитал. IoC можно вообще убрать, написав свой контейнер или взяв простой существующий. System.ComponentModel.Design.ServiceContainer, например (хотя, если вы джавист, то это вам ничего не скажет).

    Фишка удобства тестирования не выходит из концепции Unity, а выходит из концепции построения классов, которые удовлетворяют шаблону определения зависимостей. Ты должен или проставить зависимость в конструкторе или в свойстве класса, причем, желательно определив интерфейс. Значит, очень легко настроить mock зависимостей (мок интерфейса очень легко сделать) и протестировать фукнционал класса. Unity контейнер здесь не причем. Он всего лишь вставляет зависимости.

  • Почему Mono хорош
    +2
    >т.к. WinForms похожа на задницу, между прочим

    я прям физически ощущаю вброс:)
  • ASP.NET MVC Framework – ставим точки
    0
    да сам асп-нет тут не причем. Это тоже черный ящик. Фишка в низкой связности и (что очень важно), поняности этой низкой связности. Микросервисы, контейнер, блаблабла
  • ASP.NET MVC Framework – ставим точки
    +2
    Самое зло в жизненном цикле объектов:)
  • ASP.NET MVC Framework – ставим точки
    +15
    Извините, но вы профан. Вы просто не понимаете того, о чем вы говорите.
  • ASP.NET MVC Framework – ставим точки
    +2
    Круто%) Мне вот нужен был asp.net mvc, чтобы его можно было сынтегрировать с юнити. А это в свою очередь нужно для черных ящиков, которые пишут разные люди:)
  • DI и IoC для начинающих
    0
    А вот есть прикольная задачка уже не для начинающих — связать ASP.NET MVC с Unity. Требований в целом три:

    — обеспечить связывание инфраструктуры контроллеров MVC с инъектором
    — модульность
    — уникальность контейнера в разрезе сессии

    Я бы расписал все, но блин, не успеваю вообще ничего, кроме работы. А вам в рамках обучающих методик будет полезно, имхо.
  • Несколько полезных аспектов для PostSharp
    0
    Сенкс за совет. Зачем статью писали, если все в вебкасте есть?
  • Несколько полезных аспектов для PostSharp
    0
    Сори за брюзжание. Собственно, механизм связывания непонятен. Как постшарп интегрируется в приложение? Что нужно добавить, какие свойства прописать? Как это работает?:) Конечно, можно полезть на сайт и все выяснить, но вы же взялись статью писать, да?:)
  • Несколько полезных аспектов для PostSharp
    –1
    Супер — намонстрячили кучу классов-аспектов. А как же все это дело заюзать — нипаняяяяяяяяяяяяяяятна
  • Дайте мне работать-2
    +8
    >> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
    Я целиком и полностью согласен с Джоелем Спольским — спец может быть умным и может делать дела. Художник в вашем понимании по определению делать второе не в состоянии (читаем про рутину и баги в топике — обычный процесс любого программиста). Ему важно что-то сделать на модных рюшечках, «предоставить инфраструктуру», как они любят говорить (а дальше с багами вы сами ебитесь).

    У меня есть такой художник в команде — собственно, написал доменную модель и слой данных на проекте. Баги искать не хочет, тестировать не хочет — правит что-то только после того, как мордой тыкнешь. Уходить тоже не хочет — обиделся, надулся на всех, сидит сычем в своем закутке, что-то налево делает. В общем, иметь таких художников на проекте — врагу не пожелаешь.

    Вообще, с делением на два вида я бы не соглашался. Как минимум любого разработчика можно классифицировать на четыре типа:
    1) те, кто умен, и кто может доводить дела до завершения
    2) те, кто умен, но не может доводить дела до завершения
    3) те, кто не умен, но может доводить дела до завершения
    4) те, кто не умен, и не может доводить дела до завершения

    Как правило, тип 3 и 4 не проходят испытательный срок. Но тип 3 был очень распространен в докизисные времена, и, судя по всему, раз автору удалось поработать в РБК-Софте, то таджики — как раз про них.

    Вообще, как писал один мудрый человек тут:
    По симптомам это типичная ошибка, увы. Наверное, чуть ли не каждый разработчик в своей карьере пытается написать какой-нибудь обобщенный управлятор. Из этого ничего не получается, после чего возможны два варианта — либо разработчик ничего не понимает и считает, например, что управлятор был недостаточно обобщенным, либо переходит на светлую сторону и становится хорошим программистом.
    А вы сами, судя по всему, что вы тут пишете про баги и рутину, тип 2 — истинный творец или еще не написали свой управлятор:)

    И еще совет — МакКоннела прочитайте. Ну честно, прочитайте МакКоннела. Если читали, перечитайте еще раз, более вдумчиво — там с цифрами, с толком, с расстановкой. Как раз про то, что вы тут говорите, но с совершенно другими выводами. Может, поймете что.
  • Дайте мне работать!
    0
    видимо, вас могут понимать только телепаты. удачи.
  • Дайте мне работать!
    +3
    Я было вам начал что-то писать-строчить, да потом подумал, что горбатого могила исправит. Пока сами не докумекаете, что в любом бизнесе, основанном на законах нынешнего государства, первичны прежде всего деньги и все процессы разработки должны быть направлены именно на их получение, с вами бесполезно разговаривать. Можно только читать ваши «смотрите-какой-я-дартаньян» статейки, зычно ржать и показывать на вас пальцем.

    В любом случае, желаю вам поумнеть поскорее.
  • Дайте мне работать!
    +8
    >Работает? Ничего не трогай!
    Вы — не айти-художник, вы баклан. Поставьте себя на место менеджера — у него есть проект, есть какое-то количество кода, более менее оттестированного и (что самое главное), работающего.

    Тут приходите вы и все ломаете. Все что работало, и все, что уже было оттестировано. Творческая личность, ага.
  • Помогли ли вам какие-либо методы восстановления зрения?
    0
    Три-четыре года назад было -2.50. Сейчас -1.75. Ничего не делал специально:) За компом сижу постоянно.
  • Инструменты инфраструктурной поддержки для Agile проекта на Java
    0
    Соглашусь:) Мы чертим фломиком на бумажке, которая прилеплена магнитом на доске. Гораздо нагляднее:)