Ни для кого не секрет, что .net сейчас используется в большинстве случаев как инструмент бэкенд разработки, а в клиентской разработке последние лет 5 правит js сообщество с своей экосистемой и инструментами для разработки. Это все безобразие с каждым годом усиливает пропасть между фронтэндом и бэкендом, и планка вхождения в область становится все выше и выше, разработчики начинают делиться на два лагеря и уходит такое понятие как фуллстек.

Да, под Node.js можно написать сервер, но для бэковой разработки, все же, .net бесспорный лидер. На js, на мой взгляд, очень сложно написать гибкий и легко поддерживаемый бэкенд, хотя возможно многие со мной и не согласятся.

Давайте ударим автопробегом по бездорожью попытаемся вопреки всему этому написать SPA приложение с бэком на .net core и клиентом на js, из инструментов разработки будем использовать горячо любимую Visual Studio.

После этого туториала, я надеюсь, веб и бэк разработчикам будет проще найти почву под ногами в вражьей области и понять в какую сторону двигаться для более углубленного изучения. Поехали!

Я знаю, о чём вы подумали: «Ещё одна скучная статья про DRY? Нам их мало, что ли?».

Возможно, вы правы. Но я встречаю слишком много разработчиков (junior и senior), применяющих DRY так, словно они охотятся на ведьм. Либо совершенно непредсказуемо, либо везде, где можно. Так что, судя по всему, в интернете никогда не будет достаточно статей о принципе DRY.

Если кто не знает: принцип DRY — это "Don't Repeat Yourself" (не повторяйся), и впервые о нём упомянуто в книге The Pragmatic Programmer. Хотя сам по себе этот принцип был известен и применялся задолго до появления книги, однако в ней ему было дано название и точное определение.

Итак, без лишних рассуждений отправимся в путешествие по чудесной стране DRY!

Эту книгу советует Алан Кей. Он часто говорит фразу «Компьютерная революция еще не случилась.» Но компьютерная революция началась. Точнее — ее начали. Ее начали определенные люди, с определенными ценностями и у них было видение, задумки, план. Исходя из каких предпосылок революционеры создали план? По каким причинам? Куда они замыслили вести человечество? На каком этапе мы сейчас?

(За перевод спасибо Oxoron, кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru)

От переводчика

Мы — внедрители. Мы должны внедрять, а не фантазировать!
(Рина Зеленая, к/ф «Девушка без адреса»)

К переводу этой статьи меня побудили две причины: 1) желание лучше разобраться с фреймворком Spring, 2) небольшое количество источников по теме на русском языке.

Краеугольный камень ООП — «внедрение зависимостей». Если описание процесса «внедрения» в целом, удовлетворительно, то объяснение понятия «зависимость» обычно оставляют за скобками. На мой взгляд, это существенное упущение.



Чтобы не фантазировать, а внедрять, нужно сначала разобраться с тем, что мы внедряем. И в этом нам может помочь лаконичная статья Jakob Jenkov «Understanding Dependencies». Она будет полезна не только тем, кто пишет на Java, но и тем, кто пишет на других языках и следит за качеством проектирования приложений.

UPD: Я перевел еще одну статью Jakob Jenkov о зависимостях. Читайте на Хабре перевод статьи Dependency Injection, которая открывает одноименную серию статей и по смыслу продолжает данную статью. В статьях серии рассматриваются такие понятия как Dependency, Dependency Injection (DI), DI-контейнеры.

Эта статья является продолжением темы «неквалифицированного заказчика», а также попыткой проанализировать причины взаимной неудовлетворенности менеджеров и специалистов в неудачных проектах. Думаю, что моим коллегам знакома ситуация, когда проект провалился и команда пытается понять причины.

Толчком для формулирования концепции «неквалифицированного исполнителя» послужила «Черная книга менеджера» Славы Панкратова, а точнее, кусочек из главы 5 «Люди».

Если человек чего-то не делает, есть 4 причины

1. Не понял
2. Не умеет
3. Не может
4. Не хочет»

Именно в такой последовательности эти причины следует рассматривать. Но вот как понять, какая из них привела к неудаче? Идти сверху вниз и использовать методы наблюдения? Просто поговорить «начистоту»? Но не факт, что в результате получим правильное понимание.

Решение я нашел в методологии теории деятельности, элементы которой описаны, например, в статье Елены Мундриевской (ссылки на авторов приведены в конце публикации). Автор статьи приводит некую аксиому (или предикат) деятельности, при следовании которой результат на выходе будет соответствовать заданию на входе. Мне показалось, что разбор ошибок и неудач с использованием этой методики помогает правильно определить причины поражения.

Рассказывать айтишникам про психологию то еще дело, некоторые читатели скажут: «Bullshit!», и вообще не поверят, потому что психологию, даже прикладную, нельзя назвать точной наукой. Тем не менее, задача этой статьи — показать и доказать вам, что некоторые модели действительно работают. В основе доклад Сергея Котырева из UMI на РИТ++ 2017, от его лица дальше и пойдет повествование.



Я — IT-предприниматель с 20 летним стажем. Так получилось, что с самого начала карьеры мне пришлось управлять людьми. Как выпускник технического вуза и айтишник, я изначально понял, что люди сложно поддаются алгоритмизации, и вообще осознанию, пониманию и прогнозированию.

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

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

Этим летом я прочитал книгу Илона Маска Tesla, SpaceX, and the Quest for a Fantastic Future. Замечательное чтиво и подробный рассказа о взлётах и падениях одного из крупнейших визионеров нашего времени. Также книга позволила ознакомиться с рабочей этикой Маска и секретами продуктивности, которыми он пользуется для управления несколькими компаниями.

Этот список появился как личная памятка по темам, которые я обсуждал с коллегами и друзьями и в которых хотел разобраться поглубже…

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

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

В постмортемах многих игр часто повторяется одно и то же клише. Оно всплывает и в разговорах с инди-разработчиками. Звучит клише примерно так: «Чёртовы потребители! Они каждый день тратят по пять баксов на один и тот же безвкусный латте из Starbucks, но не могут выделить ту же сумму на покупку моей созданной с любовью, графически красивой инди-игры, которую я, вложив душу, разрабатывал целых три года? Почему, почему люди не могут дать моей игре шанса?»

Да, выбор кажется очевидным: или один и тот же пережаренный кофе или поистине независимое творение мысли.

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

Нежелание покупателя тратить пять долларов на странную инди-игру связано с тем, что он не представляет, какая она. Хорошо ли она сделана? Как долго можно в неё играть? На что похожа эта игра? Но, что более важно — кто её сделал? В конце концов, нам, инди-разработчикам нужно преодолеть огромное препятствие: установить взаимоотношения с нашими игроками, чтобы они доверяли нам и покупали наши игры.

«То, что привело вас к успеху, может стать неэффективным в будущем.»

Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2244 в закладки, 351k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Давайте ее переведем, ведь мужик дело говорит.

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

Мы уже перевели 8 (из 30) глав.

Глава 26. Эксперты

(За перевод спасибо Mitroshin Evgeny, который откликнулся на мой призыв в «предыдущей главе».) Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru

Как было отмечено в пятой главе, количество проблем предстающих перед нами растёт экспоненциально, и в качестве решения, мы справляемся с этим с помощью специализации. Это высказывание с годами становится лишь более правдивым:

Эксперт — это тот, кто знает всё в чём-то малом, эрудит — это тот кто знает мало, зато обо всём.

В споре между экспертом и эрудитом эксперт обычно побеждает, просто потому что использует никому не понятные термины и ссылается на свой специфический опыт, который, часто вообще не имеет отношения к предмету спора. Однако, с мнением экспертов нужно считаться. Поскольку эксперты одновременно играют очень важную роль и, иногда, мешают развитию отрасли, их мнение нужно оценивать со всех сторон. Часто эксперт недооценивает поставленную проблему, а эрудиту не справиться с задачей в силу отсутствия глубоких знаний. Тот, кто думает, что он понимает поставленную задачу, а на самом деле нет, является настоящей напастью, по сравнению с тем, кто знает, что ничего не понимает в поставленном вопросе.

Спросите любого инди-разработчика игр, в чём заключается секрет маркетинга инди-игр, и от каждого слышите почти одинаковый ответ: нужно попасть в список рекомендаций Steam или магазина мобильных приложений, добиться обзоров в прессе, сделать так, чтобы в вашу игру сыграл популярный стример. В противном случае, игра, в которую вы вложили кучу сил и времени, просто провалится.

Но представьте рынок, на котором такие рекомендации неприменимы. На нём нет таких вещей, как Steam Launch Visibility Round или рекомендации в App Store. Что, если нет прессы, с радостью пишущей обзоры? И что, если вместо 7667 игр, выпущенных в Steam в 2017 году, в тот же год выпущено больше 100 000 новых книг? А общее количество книг на рынке превышает 4 000 000 наименований?

Введение

Давным-давно американский психолог Дж. Стоунер провел интересный эксперимент (в те времена, когда над людьми можно было так безнаказанно издеваться). Он взял группу студентов и каждому вручил опросник с (условно) дихотомическими вопросами. После того, как они ответили, Стоунер предложил им обсудить эти вопросы всем вместе. А после обсуждения еще раз ответить на те же вопросы. К его большой научной удаче, результат получился крайне интересный.

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

Вот уже несколько лет в России развивается движение открытых .NET-сообществ. Первопроходцем стало питерское сообщество SpbDotNet, стартовавшем в 2015 году. Последователем питерского сообщества стало московское сообщество MskDotNet, проводящее встречи с 2016 года. Разумеется, оба сообщества очень хорошо дружат и оказывают посильную взаимопомощь. С начала создания сообществ были проведены десятки встреч, рассказаны более сотни докладов. Отлично! Давайте немного поговорим о настоящем и будущем .NET движений.

День сегодняшний

За время существования наших замечательных коммьюнити были проведены десятки встреч, обсуждены тысячи вопросов, как в форме докладов, так и в форме живого общения в кулуарах. Многие познакомились с новыми коллегами, обзавелись полезными связями, нашли ответы на интересующие их вопросы, получили море позитива, а кто-то даже нашёл новых друзей. Те, кто по каким-либо причинам не посещают, или не могут посетить наши встречи вживую — смотрят наши видео на youtube. Кстати, на данный момент наш YouTube-канал пополняется записями и с MskDotNet и c SpbDotNet. На нём выложены уже более 70 видео с докладами. Звучит просто отлично!

«Какие у вас есть вопросы?» – вопрос, который гарантирован на любом собеседовании на работу.
«И если у кандидата нет вопросов, то вопрос возникает по поводу кандидата» – как-то сказала мне знакомая HR из Кремниевой долины в разговоре о поиске работы в США.

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

На эту тему недавно нашла занимательный сайтик-генератор вопросов для интервью KeyValues.com. Для тех, кто не владеет английским в достаточной мере, я и решила сделать перевод.

Мы начинаем профессиональный «разбор полетов» выступлений с HighLoad++, который поможет многим будущим и нынешним спикерам поучиться на чужих примерах. В прошлой публикации я рассказывал о том, что именно я буду делать и зачем все это нужно. Завершать каждый материал будет небольшой рассказ о важности какого-то определенного параметра в выступлении.



Первым под прицел попал Артем Данилов из Авито и его доклад про хранилище данных. В конце же вас ждет экскурс про дикцию.

Когда много лет подряд Microsoft лихорадит из одной крайности в другую, то понемногу начинаешь привыкать к этому и все новое ждешь с неким скепсисом. Со временем это чувство становится только сильнее и подсознательно ничего хорошего уже не ожидаешь.

Но иногда все получается в точности да наоборот. Microsoft вываливает из коробки идеально работающий функционал, который рвет все устоявшиеся жизненные стереотипы. Ты ждешь от новой функционала очередных граблей, но, с каждой минутой, все больше понимаешь, что именно этого тебе не хватало все эти годы.

Такое пафосное вступление имеет определенные на то основания, поскольку долгое время на Microsoft Connect поддержка работы с JSON на SQL Server была одной из самых востребованных фич. Шли годы и неожиданно данный функционал реализовали вместе с релизом SQL Server 2016. Забегая вперед скажу, что вышло очень даже хорошо, но Microsoft не остановилась на этом и в SQL Server 2017 существенно улучшили производительность и без того быстрого JSON парсера.

Многие из нас бывали на айтишных конференциях. А если не бывали, то наверняка смотрели трансляции, записи или читали расшифровки докладов на Хабре. А вы знаете, какие доклады становятся хитами даже на самых-самых хардкорных мероприятиях? Внутренности сложных технологий? Нет. DevOps? Отнюдь. Чаще всего приз зрительских симпатий берут так называемые доклады-кейноуты — презентации людей, вовсе не обязательно связанных с IT. Дело не в красивой презентации и даже не в харизме докладчика, а в том, что эти ребята знают секрет SUCCES. Нет, мы не опечатались.

Источник: Duran

Когда появились первые ЭКВМ, бухгалтеры, счетоводы и статистики всех контор СССР не упускали момента, чтобы вернуться к привычным счётам. Потом с недоверием смотрели на первые настольные CITIZEN на батарейках и не знали, что жизнь приготовила для них сюрприз в виде 1С. Интересная была ситуация: часть работников с азартом осваивали новую программу в учебных центрах, часть — того же возраста — переходили на другую работу или продолжали делать всё по старинке. Сейчас различные технологии внедрены повсеместно, но ситуация не меняется: каждая новая программа вызывает волну недовольства и протеста у сотрудников нетехнического профиля. Компании впустую тратят деньги на обучение, дорогой софт простаивает, продуктивность стоит на месте или снижается. Плюнуть и забить — слишком дорого для бизнеса. Принуждать — терять людей и нервы. Есть выход — правильно обучать. Время зарыть топор войны физиков и лириков и поговорить о том, как жить дружно.

Источник

Время можно анализировать с двух разных точек зрения: объективной и психологической (субъективной). Когда мы говорим о времени, которое измеряется при помощи часов, мы говорим об объективном времени или времени, измеряемом по часам. Оно обычно отличается от времени в восприятии пользователей, ожидающих реакции на свои действия на сайте или в приложении.

Оглавление серии «Производительность как восприятие»:

• Производительность как восприятие: восприятие времени;
• Производительность как восприятие: управление восприятием; (эта статья)
• Производительность как восприятие: управление терпением.

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

Каждый вариант учета времени имеет свои ограничения.

Статья написана как для руководителей, так и для программистов, т.к. описанные методы применимы и для подчиненных, и для себя.

Сначала кратко методику (не все с ней работали), потом – главное, зачем ее применять.

Методика измерения

Сама методика известна давно, никакого секрета собой не представляет – это покер планирования из Scrum. Чтобы ее применять, не нужно применять весь Scrum.