• 5 различий работы аналитика в проектах и продуктовой разработке
    0
    ИМХО, в терминах PMBoK или IPMA «управление продуктом» неплохо ложится на «управление программой».
  • Тестируем пользовательские сценарии вместе с «Гермионой». Лекция Яндекса
    +4
    1) Не понял, при чём тут интеграционное тестирование, если повествование о фронтенде. Обычное функциональное тестирование.

    2) Статья одного маркетолога для других. Так никакой конкретики и не нашёл. Полстатьи шуток-прибауток, затем поток названий всевозможных инструментов. А применять это как? Показали бы пару примеров НЕ «Hello world». Раз у вас такая крутая команда, могли бы что-нибудь интересное наскрести.
  • Совмещение труда в разработке программного обеспечения
    0
    Любую модель разграничения ответственности и ролей можно поставить под сомнение при желании. В том смысле, что для любой методологии всегда найдётся такая команда, которой эта самая методология не подойдёт.
    Возможно, по прочтении статьи может сложиться впечатление о безальтернативности матрицы из MSF, но я не намеревался выставить это в таком свете.
  • Совмещение труда в разработке программного обеспечения
    0
    Очень эмоционально получилось. Я так понял, что основная мысль здесь была про недооценку важности специалистов техподдержки? Согласен, что многие разработчики недооценивают на этапе проектирования и даже сдачи проекта важности наличия необходимого функционала у операторов, способов восприятия информации простыми пользователями, нет понимания целей, которые преследуют эти самые пользователи.
    Но у нас в конторе для этого на этапе сдачи проекта привлекаются спецы и их начальники, ответственные за поддержку клиентов в затрагиваемой области. Они себе не враги и тупо не примут в эксплуатацию недоработанную систему.
    Если же где-то это «прокатывает», то при честной и открытой игре они просто не выдержат конкуренции и покинут рынок в качестве самостоятельного игрока.
  • Agent Intelligence от ServiceNow — нейронные сети на службе у техподдержки
    0
    Поддерживаю предыдущего оратора. Какие источники данных можно подключить? Какие виды информации кроме текста анализируются на входе? И проч.
  • Несколько аргументов против Dependency Injection и Inversion of Control
    –1
    1) Я не спрашивал кто будет лезть в код, когда программист уволится. Я спрашивал «кто отвечает за код в процессе». Если никто не отвечает, то вам и без DI наворотят, вплоть до "#define TRUE FALSE", и спросить не с кого.

    Тогда может возникнуть вопрос, а кто отвечает за тех, кто отвечает за код. Ну был архитектор, ни которого я полагался. И по факту никакого времени у него не было, чтобы реально оценить решение.А вообще не понятно, куда вы уводите дискуссию.
    Отвечает за проект РП. Он и виноват в итоге. С себя я вины не снимаю. Но и не вижу противоречий с моим посылом, что при написании программы, было неплохо подумать о тех людях, которые с этим потом будут разибираться. Может, это будет РП, может — программист-стажёр, может — перешедший с других технологий.

    2) Ну так Вы и оценивайте сможете ли Вы правильно использовать.Если нет — не нужны статьи про DI, это нефункциональное требование «мне лень в этом разбираться — делаем по-старинке».

    Мне кажется, что вы недостаточно хорошо меня знаете, чтобы с такой лёгкостью обвинять меня в лени. Потрудитесь, прощу вас, почитать мою статью ещё раз (в особенности — выводы) и указать, что именно в ней не так сказано

    3) Так получается, вы и не РП. Ну или «и жнец и кузнец и на дуде игрец», плохо справляющийся со всем (ни в DI разобраться времени не нашли, и бюджет съеден, и код не отревьюен).

    О своих управленческих ошибках я не забыл упомянуть в своей статье. т.ч. на чём вы меня пытаетесь подловить?
    Жизнь оказывается несколько сложнее, чем наши идеалистические представления. Полицейские должны ловить преступников, а не копаться в кипах бумаг, чиновники должны исходить с позиций долга перед обществом и ставить интересы социума выше своих личных, врачи должна оказывать квалифицированную помощь бесплатно. Ну должны. Тут вопрос, скорее, философский. Сделать так, чтобы наверняка. Или наваять по науке, а потом сетовать на окружающий мир за непонятый замысел. Мне ближе 1-ый вариант.
  • Несколько аргументов против Dependency Injection и Inversion of Control
    0
    Самое забавное, что все (ну ладно, многие) считают, что они пишут для себя. Отсюда и такое как у Вас отношение. Пишите так, чтобы другие сказали, что вы пишете понятно. Исли изначально исходить из таких предпосылок, то и вопросов о читаемости не возникнет.

    Вот и про то же. Причём и вполне себе опытные спецы могут так делать. Как я писал в начале статьи, на мой ИМХО, очень мало акцентируется внимания в статьях и книгах, поэтому, когда мозг проектировщика начинает усиленно переваривать ТЗ, на уровне подкорки не возникает желания взглянуть на продукт с точки зрения тех, кто будет его запускать, сопровождать и развивать.

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

    Задним умом мы всегда умные. Но, как правило, ближе к запуске проекта ни бюджета, ни времени, ни сил уже нет на то, чтобы переделывать архитектуру.
    С точки зрения архитектуры я привел стати авторов, которые утверждали, что IoC вполне может применяться, если, например, может быть несколько стратегий поведения.
  • Несколько аргументов против Dependency Injection и Inversion of Control
    –5
    Про сферических коней в вакууме я уже писал выше. Когда вы несколько дней подряд посидите по 12-16ч на работе или 3-4 недели без выходных, я посмотрю на вас, с каким энтузиазмом вы будете писать автотесты.
    В-вторых, организация тестовой среды в интеграционном проекте часто бывает делом далеко не тривиальным.
  • Несколько аргументов против Dependency Injection и Inversion of Control
    0
    У вас РП лазает в код?

    Если старый бюджет съеден, а новый будет только после запуска, то запускать придётся самому.
  • Несколько аргументов против Dependency Injection и Inversion of Control
    –2
    Ну, так это проблема не Smart Client, а организации работы в команде. Если у вас только один понимает архитектуру проекта, то это закономерно приведет к таким последствиям, вне зависимости от того, какие инструменты, библиотеки и т.п. вы используете.

    Вот именно это и побудило меня на написание этой статьи. Организация не та, организаторы не те, организуемые не те, сфера образования не та, пользователи не такие и т.д.
    А можно просто делать просто, чтобы было понятно даже стажёру.
    Автомат Калашникова никогда не отличался рекордами в своих стрелковых характеристика, но простота обслуживания, чистки, устойчивости к факторам внешней среды обсуловила всемирную популярность.
  • Несколько аргументов против Dependency Injection и Inversion of Control
    –5
    Хотел бы заступиться за Smart Client.

    Пока у меня был программист, который стоял у истоков создания этого приложения, который понимал всю эту штуку в целом, меня всё устраивало. Проблемы начались, когда я остался один.
    На самом деле к DI/IoC надо прийти.

    Безусловно. С этим никто не спорит. Но с точки зрения РП, как можно в самом начале оценить, будет разработчик правильно использовать или нет? Я могу поверить, что в этом есть что-то изящное, но простым смертным не всегда доступное. :)
  • Несколько аргументов против Dependency Injection и Inversion of Control
    0
    под слабой связанности вы тут именно cohesion или coupling имеете ввиду?

    Имею в виду инстанцирование в runtime-е.
    Интересно каким образом DI/IoC нарушает инкапсуляцию.

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

    Разумеется. Об этом и речь. Других под рукой не было :)
    То есть это в целом проблема инстанциирования большого графа зависимостей. нет? Причем тут IoC/DI? Ну и еще есть простой лайфхак. если между кодом который вызывает и кодом который выполняет тонны абстракций, их можно спрятать/выкидывать грепом. Как правило у таких вещей будет вполне себе явный нэймспейс и можно легко фильтровать стэктрейсы

    Вполне допускаю, что есть хорошие способы. Вопрос к авторам кода, почему их не использовали. Возможно, на тот момент какая-то книжка была прочитана наполовину. :)
    причем тут IoC/DI? Если система спроектирована плохо,

    Разумеется. Плохо. С IoC/DI это сделать очень просто. ИМХО.
    Я так и не увидел предлагаемой альтернативы. Более того я так и не понял что плохого вы видите в IoC. Есть подозрение что под IoC вы имеете ввиду контейнер зависимостей а не сам принцип.

    Наверное, альтернатив может быть много. Тут я не берусь навязывать.

  • Несколько аргументов против Dependency Injection и Inversion of Control
    +3
    Вот вы пригласите почитать кого-нибудь со стороны почитать ваш код, и пусть он скажет. :)

    А размер проекта вообще на сложность не влияет

    Вот это поворт :)
  • Несколько аргументов против Dependency Injection и Inversion of Control
    0
    Долго думал, в Управление проектами или в Разработку, ну пусть лежит здесь
  • UI controls на русском
    +1

    В научных статьях нужно указывать ключевые слова. Может, и здесь подойдёт? "Ключевые слова", "список/перечень ключевых слов".

  • Практическая безопасность: тренды и прогнозы-2015
    +4
    Мне кажется, самое актуальное на протяжении последних лет направление защиты не указано – просвещение. )))

    Или это не тренд?
  • Делить на ноль — это норма. Часть 1
    +3
    Подозреваю, что школьный анекдот про «квадратный корень» и «многочлен» Вы тоже не слышали?
  • Делить на ноль — это норма. Часть 1
    0
    Как читатель, получивший диплом 10 лет назад и ни разу на практике теорию чисел (да и почти всего остального тоже) не применявший, я понял так, что:

    1. В стандартных теориях введение исключений при делении на 0 позволяет избавиться от противоречий (и головняка) в свойствах поверх аксиоматики.
    2. В данной статье описывается, как предки предложили специальные обозначения для двух типов сложных ситуаций, и в общем никто не запрещает эти случаи ещё раздробить – как обычно говорится в таких случаях, читателю предлагается проделать это самостоятельно [при желании].
  • Методологии управления информационными проектами
    0
    Это так. Но всё-таки есть объективный критерий: кто раньше выпустил/опубликовал документ, тот и первый.

    Возможно, был в СССР некий отраслевой стандарт или внутриведомственная инструкция.

    Для примера (к теме не относится). Наткнулся в своё время на ОСТ 4.071.030.
  • Методологии управления информационными проектами
    +3
    Спасибо за DSDM, т.к. нашёл там полезную инфу для своей статьи в периодическом издании)))

    Теперь критика.

    1. Мне кажется, не стоит умалчивать об управлении проектами в общем. Те же PMBoK, PRINCE/PRINCE2 и прочие вполне подходят и для управления ИТ-проектами. Просто различные RUP, MSF, Agile и т.д. более подробно останавливаются на отдельных специфицеских для ИТ моментах.
    2. Гляньте ещё в сторону SWEBOK.
    3. Есть у меня товарищ, утверждающий, что PMBoK слизан с наработок в СССР. Мне не удалось пока найти ни подтверждений, ни опровержений этого тезиса. Если бы Вам удалось что-то найти про отечественный опыт – это бы стало дополнительной «изюминкой», которую, кстати, очень любят в наших научных кругах (ИМХО – и правильно делают).
  • Количество бюджетных мест в вузах на IT-специальности в 2015 году увеличится на 35%
    +1
    Слюной брызжут на других ресурсах, уважаемый. А здесь люди собрались, которые споря приводят аргументы.
  • Количество бюджетных мест в вузах на IT-специальности в 2015 году увеличится на 35%
    +3
    Северная Корея же.
  • Количество бюджетных мест в вузах на IT-специальности в 2015 году увеличится на 35%
    –2
    Что-то Вы навалили всё в одну кучу, даже не знаю с чего начать.

    Лично я считаю, что увеличение бюджетных мест по данному направлению – в любом случае позитивное изменение, особенно на фоне снижения доступности высшего образования в целом по стране.

    Википедия, конечно, – авторитетный источник (ага). Но предлагаю Вам обращаться также и к другим источникам. Вот в ежегодных исследованиях Руссофт (см. раздел 6.1. в последнем отчете) среди прочего отмечается, что применительно к ИТ-специалистам миграция не оказывает определяющего значения. А вот вузы, как раз, оказывают.

    Кстати, в этих же исследованиях строятся прогнозы по количеству необходимых специалистов. И там выделяются 3 варианта развития событий. Поэтому опрос в статье считаю сформулированным не совсем корректно.

    Про биткойны и проч. молчу, т.к. это отдельная тема.
  • Изначально ущербная система подготовки к переговорам
    0
    Если ваш проект-менеджер пишет вам с ошибками...


    «Руководитель проекта(-ов)», ну или, на худой конец, «менеджер проекта(-ов)» / «проектный менеджер». )))
  • Использование возможностей NHibernate в Orchard.CMS
    0
    Тогда не забудьте с нами поделиться, когда проведёте. Было бы очень интересно. ))
  • Использование возможностей NHibernate в Orchard.CMS
    0
    Это всё хорошо, а нагрузочное тестирование различных вариантов проводились?
  • Как будет выглядеть поселение на Марсе?
    0
    Вы за новостями хоть немного следите? )))
  • Новинки осени: видеообзор Lumia 830 и Lumia 730 / 735
    0
    Так рекламируют камеры, а ни одной фотки так и не сделали (я про 730/735) :(
  • Waterfall и Agile: и всё-таки, откуда эффект?
    0
    Статью плюсую, ибо считаю, что уже сама попытка что-то смоделировать и вывести формулу для практического применения достойна похвалы. Но вообще говоря, содержимое статьи вызывает противоречивые чувства, и практически по каждому пункту можно дискутировать. Но чтобы не ломать копья зазря, я бы Вам посоветовал:

    1. Чётче обозначить цели Вашего исследования (это сравнительный анализ или что?) и описать соответствующие им полученные результаты.
    2. Очертить границы рассматриваемых случаев и допустимости применения Ваших методов. Допускаю, что в отдельных случаях, оценка трудозатрат с применением Вашего подхода может быть вполне приемлемой (с оглядкой на трудозатраты по получению самой оценки). Но всё же следует это всё оговорить. Вот Вы строите графики для N=10, а мне мой опыт подсказывает, что проект с 10-ю разработчиками – это уже весьма объёмный проект. И здесь если и применять грубые оценки, то только совместно с риск-менеджементом и резервированием времени/бюджета.

    Из замечаний по сути я особо выделил момент с n(t):
    1. Всё-таки делать какие-то выводы на одном-единственном примере не айс. Тем более что у меня лично, как сталкивавшегося в основном именно с водопадом, есть возражения по поводу типичности такого примера с колоколообразной функцией распределения.
    2. Эта функция в принципе не может быть непрерывной. Сразу вспоминаются 2,5 землекопа из Страны невыученных уроков. ;-)))
  • На собрании Сбербанка Греф выступал в Google Glass и говорил о конкуренции с Google и Amazon
    –14
    Вы не представили ничего нового по сравнению с материалами обычных новостных агентств. Если у вас есть подробности выступления Грефа (касательно ИТ), то потрудитесь их вынести в статью. Пожалуйста.
  • Тестирование производительности платформы Docsvision c Visual Studio
    +1
    Помнится, в 2009-м во времена DV 3.x на форумах народ жаловался, что у кого-то система забивает канал уже при 10 одновременных пользователях (в корпоративных сетях с сотрудниками, также работающими с другими программами). В своих тестах вы это учитываете? А то из представленной выше конфигурации это не очевидно.
  • UI controls на русском
    0
    Автозаполнение в моём понимании предполагает действие программы заместо пользователя. Как Т9 иногда действует. А автоподсказка предполагает более мягкие действия со стороны системы.
  • UI controls на русском
    +1
    Не вижу ничего плохого в слове «выпадать», Ваш вариант, тем не менее, добавил. А MS не всегда следует в качестве авторитета приводить. «Обозреватель» к тому подтверждение.
  • UI controls на русском
    +1
    Label — метка

    ИМХО плохо, т.к. не отражает суть – это текст, а не чёрная метка.

    Tab — вкладка (ибо закладка — это скорее bookmark)

    Как вариант добавлю. Но с многозначностью русских терминов вообще проблема.

    Icon — значок

    Ну… ОК.

    Canvas — холст, канва

    ОК.

    Grid — сетка.

    Как вариант уже есть. Но здесь, видимо, от контекста нужно выбирать вариант перевода. Если для вывода данных используется, то ближе «таблица». А для выравнивания элементов в контейнере – «сетка».
  • Нужен ли на Хабрахабре отдельный хаб об айтишной терминологии?
    +1
    Все пропагандисты идеи адаптивного/вдумчивого перевода подчёркивают: никто не пытается запретить заимствования. Даже академик Зализняк в своей лекции об этом говорит. В основном авторы обращают внимание на 2 аспекта:
    1. калькирование при наличии уже существующего достойного аналога в русском языке;
    2. использование нехарактерной для русской грамматики и морфологии приёмов за счёт прямой транслитерации.


    В ИТ очень много неудачных терминов, т.ч. всех призываю кликать маусом на первом пункте опроса ;-)
  • История о парсинге одного aspx сайта
    –4
    пагинация


    Какая в пиццду вагинация? Чем плох термин «постраничный вывод»?
  • 4 причины, почему люди чего-то не делают или “Как раскачать low-performer’а”
    +1
    Кстати, конкретно Максиму цель вообще не озвучили, а поставили задачу. Задача != цель ))))
  • 4 причины, почему люди чего-то не делают или “Как раскачать low-performer’а”
    0
    Я всё-таки не про Максима, а про «всегда, безоговорочно». Меня смущает именно эта категоричность и безапелляционность.

    Если говорить про цели, то мне привычней думать о SMART-целях. В таком случае, среди прочего, цель должна быть чётко сформулирована и измеряема. А это уже работа специалиста.
  • 4 причины, почему люди чего-то не делают или “Как раскачать low-performer’а”
    –1
    Позволю себе усомниться во «всегда, безоговорочно». Есть такой вид начальников, которые во всём разбираются и любого подчинённого за пояс заткнут. И подчинённые им нужны лишь в виде недостающих рук, анецефалов.

    Но вполне заслуживает права на жизнь ситуация, когда специалисты набираются для решения проблем в той области, в которой «плавает» руководитель команды. Здесь подчинённый должен сам поучаствовать в постановке задачи.
  • Битва за «Электро-Л»
    +16
    Hello, IT. Have you tried turning it off and on again?