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

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

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

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

Источник: Duran

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

Источник

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

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

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

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

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

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

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

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

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

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



Практически все, кто пользуется современными средствами обмена сообщениями, сталкивались с ботами. Одно из определений бота – это программа, выполняющая автоматически и/или по заданному расписанию какие-либо действия через интерфейсы, предназначенные для людей.

Боты могут использоваться для информирования, для автоматизации процессов (например, автоматической генерации задачи в TFS на основе письма пользователя) и для многих других целей, но т.к. одной статьи не хватит, чтобы рассмотреть все варианты, далее пойдёт рассказ лишь о том, как создать бота для обработки команд.

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

Уже тысячи и тысячи мужчин и женщин по всему миру используют этот современный подход, который гарантирует потрясающие выигрыши в производительности и эффективности по сравнению с устаревшими методиками, такими, как Scrum, Agile, Kanban.

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

Итак, встречайте — Porozhnyak!

Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

Кошка сдохла, хвост облез – кто слово скажет, тот ее и съест. Все знают эту детскую считалочку.

Но сегодня не о считалочках, а о системном мышлении и его применении для понимания бизнес-процессов предприятия.

Несмотря на множество замечательных материалов по Data Science например, от Open Data Science, я продолжаю собирать объедки с пиршества разума и продолжаю делится с вами, своим опытом по освоению навыков машинного обучения и анализа данных с нуля.

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

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

С чего начать? Конечно с открытых данных правительства РФ, там же ведь целое министерство есть. Мое знакомство с открытыми данными правительства РФ, было примерно, такое же как на иллюстрации к этой статье. Нет ну не то чтобы мне совсем не был интересен реестр Кинозалов города Новый Уренгой или перечень прокатного оборудования катка в Туле, просто для задачи регрессии они не очень подходят.

Если порыться думаю и на сайте ОД правительства РФ можно найти, что-то путное, просто не очень легко.

Данные Минфина я тоже решил оставить, на потом.

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

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



UPD: Добавлен раздел – «Бонус»

Предлагаю читателям Хабра мой перевод статьи «44 урока управления технарями» Славы Ахмечета, сооснователя RethinkDB. В оригинальной статье используется термин «инженеры», но в контексте статьи я буду использовать также термин «технари» – более емкое, как мне кажется, с точки зрения русского языка слово, охватывающее профессии в сфере ИТ, частью которой я тоже являюсь.

Немного об оригинальном тексте. Статья была написана в 2014 году в личном блоге автора, в октябре 2016 компания RethinkDB не смогла выйти в прибыль и закрылась, о чем на Хабре писали тут и тут, а Слава поразмышлял об этом здесь.

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

Источник

Вводная

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

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

Последние восемь лет Артем Ерошенко занимается автоматизацией тестирования. За это время он успел повзаимодействовать с разными командами на разных позициях, но большую часть своей карьеры проработал в команде разработки инструментов тестирования. В этой команде и родился инструмент для построения отчётов автотестов Allure, который они заопенсорсили.

Есть люди, которые не знают об этом инструменте. Поэтому мы начнем с краткого вступления в Allure report.



В основу данного материала легло выступление Артема Ерошенко на конференции Гейзенбаг 2017 Piter. На московской конференции 8-9 декабря Артем выступит с новым докладом.

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

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

Что значит имя? Роза пахнет розой,
Хоть розой назови ее, хоть нет.

• Шекспир "Ромео и Джульетта" (пер. Пастернака)

Данная статья не может служить поводом для выражения нетолерантности или дискриминации по какому-либо признаку.

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

Это примерно все равно, что сказать: вероятность быть сбитым машиной, если тебя зовут Сережа, выше, чем если бы тебя звали Костя! Звучит довольно дико, не правда ли? Ну, как минимум, ненаучно. Однако социальные сети сделали возможным сравнительно просто проверить приведенное выше утверждение.

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

1. Что такое качество в разработке ПО?
2. Во сколько нам обходится некачественное ПО?
3. Кто отвечает за качество?

Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

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

Сегодня Redux — это одно из наиболее интересных явлений мира JavaScript. Он выделяется из сотни библиотек и фреймворков тем, что грамотно решает множество разных вопросов путем введения простой и предсказуемой модели состояний, уклоне на функциональное программирование и неизменяемые данные, предоставления компактного API. Что ещё нужно для счастья? Redux — библиотека очень маленькая, и выучить её API не сложно. Но у многих людей происходит своеобразный разрыв шаблона — небольшое количество компонентов и добровольные ограничения чистых функций и неизменяемых данных могут показаться неоправданным принуждением. Каким именно образом работать в таких условиях?

В этом руководстве мы рассмотрим создание с нуля full-stack приложения с использованием Redux и Immutable-js. Применив подход TDD, пройдём все этапы конструирования Node+Redux бэкенда и React+Redux фронтенда приложения. Помимо этого мы будем использовать такие инструменты, как ES6, Babel, Socket.io, Webpack и Mocha. Набор весьма любопытный, и вы мигом его освоите!

Думаю, что рефакторинг проекта – тема, близкая каждому разработчику. Зачастую мы сталкиваемся с проблемами, когда нам перестает хватать средств IDE и регулярных выражений, и тогда на помощь приходят средства вроде тех, что описаны в этом посте. Codemod скрипты – это очень мощный инструмент. После его освоения станет ясно, что ваш рефакторинг уже никогда уже не будет прежним. Поэтому я перевел этот пост для нашего хабраблога. Желаю приятного прочтения.

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

За последние годы JavaScript изменился до неузнаваемости. Развитие этого языка привело к тому, что была изменена даже простейшая задача по объявлению переменных. В ES6 появились let и const, стрелочные функции и множество других новшеств, каждое из которых приносит пользу разработчикам.

При создании и поддержке в рабочем состоянии кода, призванного выдерживать проверку временем, растёт нагрузка на разработчиков. Из этого поста вы узнаете, как можно автоматизировать задачи по широкомасштабному рефакторингу кода с использованием Codemod-скриптов и инструмента jscodeshift, что позволит вам, например, легко обновлять свой код для использования новых возможностей языка.

Вот что строил испанский архитектор Антонио Гауди:



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


Это два крепления. Первое производится серийно — оно просто в проектировании, просто в изготовлении, дёшево и невероятно уродливо. Второе красивое, и требует на 25% меньше материала для того, чтобы выдержать тот же вес (то есть — куда прочнее). Только его трудно рассчитать, оно будет дороже в серии — и придётся подумать.

Примерно то же самое делал Гауди. Ему пришлось обойтись без математического аппарата и современных материалов. И ещё действовать в рамках строго ограниченного бюджета. Он, фактически, заложил новые принципы всего от фасада до последней дверной ручки, создал шедевры оптимизации — в общем смёл все стереотипы как сухие листья, создал с нуля теорию и воплотил её. В девятнадцатом веке всё то, что он делал, было просто диким. Некоторые даже считали его сумасшедшим.

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

Если имеется 2 предприятия, тогда вероятность того, что они оба обанкротятся, и мы потеряем все вложения $$. Так учит стандартная теория вероятности. Но что будет, если предприятия связаны, и банкротство одного ведет к банкротству другого?

Крайним случаем является ситуация, когда предприятия полностью зависимы. Вероятность двойного банкротства $$( банкрот1 & банкрот2 ) = $$( банкрот1 ), тогда вероятность потери всех вложений равна $$. Методика оценки риска имеет большой разброс $$ от 0.05 до 0.0025 и реальное значение зависит от того, насколько правильно мы оценили связанность двух событий.


При оценке инвестиций в $$ предприятий имеем $$ от $$ до $$. То есть максимальная возможная вероятность остается большой $$, и старая поговорка «не клади яйца в одну корзину» не сработает, если упадет прилавок со всеми корзинами сразу.

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

Попробуем разобрать эту проблему, решив простую математическую задачу после ката.