Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
software engineer в FrontRange Solutions
  • В Крыму усиливается дефицит разработчиков под Windows 8 и Windows Phone

    Саша, некоторых надо, сам удивляюсь.

  • Новый зарплатный опрос (декабрь 2011)

    Я надеюсь немного.

  • Влияют ли программисты на бизнес компании?

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

    Підтримав: Tanya Savchenko
  • Продуктовые компании в Киеве (Украине)

    DirectEDI (Харьков)

  • С кем никто не спорит?

    «Для начала учиться честно понимать, какую выгоду получаете вы, а какую выгоду видит ваш протеже (с его точки зрения). »

    Вот это самое сложное. Это как покер, не видя карт человека (не зная истинных причин, которыми он мотивирован), очень сложно понять, что в руке — пара двоек или фулл хаус (какую выгоду он получает).

  • С кем никто не спорит?

    Очень полезная статья, спасибо!

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

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

    Собственно вопрос — как помочь людям, чтобы желание показать свою крутость самым простым способом не доминировало над желанием эффективно решить проблему?

  • У разработки женское лицо

    Глаз радует что? Буквы? Аватарка? Слог? Вобщем да, я любитель женщин. Вы нет? Если нет, то от меня вам «тю странный».

  • У разработки женское лицо

    Мой тоже, потому о девушках в айти только хорошее впечатление.

  • У разработки женское лицо

    Ну как сказать, прямо нет.

  • У разработки женское лицо

    А мне кажется ещё какое обоснование =) По поводу кармадрочества, — я бы минусовал только когда коммент совсем уж обидный или оскорбительный.

  • У разработки женское лицо

    Каждый находит то, что хочет найти =)

  • У разработки женское лицо

    Называйте меня на ты, не велика шишка. За что меня минусовать собрались?

  • У разработки женское лицо

    Могло так показаться, но только не «что вы хотите от убогого? он же старается...». Ни в коем случае не это я хотел показать и писал без сарказма. Вольность допущений добавляет ценности в данном случае, т.к. придаёт статье свой шарм. Автор, кстати, указывала на эту вольность ещё вначале «Надеюсь, что легкое утрирование в моих аргументах не приведет к забрасыванию меня гнилыми помидорами...», но эта фраза осталась незамеченной. С тэгами «юмор» или «пятничное» шарма бы не было.

    Тем не менее мне нравится как я выразил ощущения в первом комментарии, они приятные и это главное.

  • Построение «правильного» процесса разработки на платформе.NET

    TeamCity бесплатен в версии Professional. Это 20 билд конфигураций и 20 пользователей: www.jetbrains.com/...mcity/download fromIndex

  • Карма и минусы на ДОУ

    Я тоже за минусы, но за ограниченное количество. Скажем 3 в неделю, без накопления.

  • У разработки женское лицо

    " — Но меня, конечно, не столько интересуют автобусы, телефоны и
    прочая... — Аппаратура! — подсказал клетчатый. — Совершенно верно, благодарю, — медленно говорил маг тяжелым басом, — сколько гораздо более важный вопрос: изменились ли эти горожане

    внутренне? " — Булгаков, Мастер и Маргарита

    Что же за агрессивное у нас мужское комьюнити. Читая комментарии воображение рисовало картину, когда маленькая, но очень гордая котейка отбивается мягкими лапками, не выпуская когтей, от агрессивных питбулей. Мужики! Разве вы не видите _женственность_ в каждой строчке этой статьи? Разве это не прекрасно?

    Зачем требовать логичных обоснований каждого слова (а автор на это несомненно способна, это видно по комментариям), давайте позволять каждому быть по-своему нтересным. Ценность статьи именно в этой вольности допущений, в своём особенном, «женском» стиле изложения, который мне доставил несравненное удовольствие. Это же круть несусветная, мне одному так кажется?

  • Немного о разрыве зависимостей и TDD

    Спасибо Вам за статью. Сразу хотелось бы попросить у автора прощения за следующую критику, я пишу это для того, чтобы помочь вам тоже стать лучше, как и Вы старались помочь нам и мне в частности при написании статьи. Всё полезно и интересно (даже непривычно читать на русском), но вот подход к написанию некоторых тестов расходится с best-practices индустрии, которые прововедуются в этой и этой книгах. Это не значит, что тесты плохие, просто хотелось бы обратить внимание.Если вы пишете тест с использованием мока, то в конце теста должен быть один и только одни Verify, которые проверяет ранее построенные Expectations.Если у вас есть несколько вызовов Verify — вероятно Вы тетсируете слишком много. Также в некоторых Ваших тестах это явно не моки, а стабы, а стабы как известно не могут влиять на результат выполнения теста и следовательно для них не нужно вызывать Verify.Я не хочу вызвать бурю негодования и мыслей в стиле «в интернете кто-то не прав», попытаюсь этого избежать. Давайте рассмотрим всё на конкретном примере — Ваш первый тест и будем считать, что всё написанное относится больше к нему, а к остальному с уточнениями =)

            public void DoSomething()        {            var webService = MockRepository.GenerateMock();            webService.Expect(x => x.GetCaseCount()).Return(20);            var classWithDependency = new ClassWithDependency(webService);            bool result = classWithDependency.DoSomething();            Assert.IsTrue(result);            webService.VerifyAllExpectations();        }

    Что здесь происходит? Для начала определимся, с тем что мы хотим протестировать - это метод DoSomething(). Мы фактически создаём stub, который настраиваем вот так - "Если вызван GetCaseCount, верни 20" и дальше собственно делаем утверждение, которым уже тестируем наш метод DoSomething.Вызывая в конце Verify мы ещё и проверяем был ли вызван GetCaseCount внутри тестируемого метода. Зачем? Таким образом мы смешиваем State и Interaction Testing, что нехорошо т.к. мы тестируем более одной вещи за тест. Я бы переписал тест вот так:

            public void DoSomething()        {            var webService = MockRepository.GenerateStub();            webService.Stub(x => x.GetCaseCount()).Return(20);            var classWithDependency = new ClassWithDependency(webService);            Assert.That(classWithDependency.DoSomething(), Is.True);        }

    Таким образом мы тестируем только State, нет необходимости делать ещё и Interaction testing (хотя если возникает желание, можно сделать это в отдельном тесте, где уже будет полноценный Mock) Помимо сказанного — в начале статьи Вы описываете TDD таким образом, чтобы понял даже неподготовленный читатель, затем ссылаетесь на опрос, что 70% разработчиков не пишут тестов вообще либо же имеют ограниченное покрытие, следовательно вы ориентировались на те ~ 30%, которые тесты всё таки пишут? Понять код ваших тестов не имея соответствующих знаний просто невозможно.

  • Немного о разрыве зависимостей и TDD

    2 изучающий английскийНе понял Вашего комментария, при чём тут работодатели, которые не ценят разработчиков?

← Сtrl 1234 Ctrl →