Disclaimer: в этой статье есть целый блок рассуждений о том, как считать показатели KPI для сотрудников-программистов и разработчиков — по многочисленным просьбам читателей.

KPI обсуждаются на конференциях, про KPI пишут сложные статьи в журналах, KPI ненавидят сотрудники и недолюбливают боссы. KPI своей медалькой и работой считают HR-специалисты. И почти всё это с KPI происходить не должно, потому что это обыденная метрика, показывающая результативность каждого сотрудника и обеспечивающая конвертацию результатов труда в некие баллы, а уже баллы при желании в деньги. Время идёт, проблемы не убывают, KPI в ИТ-сфере — так вообще притча во языцех. В этот раз мы решили разобрать три важных вопроса использования ключевых показателей в компаниях. Даёшь тянуть правильную морковку!


KPI должен быть правильным

Сейчас в мире как никогда интересно: страны кидаются друг в друга санкциями и ограничениями, мировой порядок теряет однополярность и обретает биполярочку новый облик. Тем интереснее, что на геополитическую арену вышел ещё один медведь — большая китайская панда. Конечно, западные и российские СМИ нет-нет, да расскажут о том, что никакое это не экономическое чудо, и вообще китайская экономика — это такой пузырь, который вот-вот… А вот-вот длится и длится, потому что, во-первых, пузырь обеспечен технологиями и товарами, а значит, лопнуть ему сложно, а во-вторых, это действительно чудо — за каких-то 50 лет (для истории и экономики это мало) вытащить страну из голодающей и убогой бедности в экспортную и инвестиционно привлекательную державу. Тут самое время просить о мастер-классе. Ведь реально есть чему поучиться.

Мир прочно подсел на колёса. Радует, что в этот раз на правильные. Среди них — самокаты. Чисто конструктивно это весьма простая штука — в уже совсем далёком детстве мы гоняли на том самом, который деревяшки и два колеса. Иногда деревяшки были расписаны городецкой росписью. Транспорт из детства жутко гремел, но казался едва ли не самым весёлым на свете, особенно когда под горку коленками об асфальт. И никто из нас и думать не мог, что снова встанет на самокат будучи взрослым. Но на какой! Лёгкая и прочная складная конструкция, бесшумные колёса, амортизаторы, тормоза и даже электромоторчик. И всё, начинается: «Я покоритель пробок! Я лечу над городом! Я гроза тротуаров! Чёрт, как его впихнуть в автобус? А он выдержит мою тушу в 90 кг? А я не окривею? А если сыну дать покататься?». Мы собрали топ самых волнующих вопросов и готовы на них ответить. Ну что, погнали?

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

Распространённый паттерн: открыть страницу поиска в Google и щёлкать по разным результатам в поисках нужной информации. Можно открыть десятки отдельных вкладок или ходить на каждый сайт по очереди, возвращаясь затем на поисковую выдачу (кнопка Back в браузере). Специалист по поисковой оптимизации Дэн Петрович из австралийской компании Dejan Marketing придумал, как эксплуатировать этот паттерн с выгодой для себя и получить обширную статистику посещений сайтов конкурентов, лишив их трафика.

Схема показана на иллюстрации вверху. Перехватывая трафик конкурентов, специалист получает возможность:

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

Q: Что у нас есть?
A: Статистика, собранная с хостов.

Q: Что мы хотим получить?
A: Топологию сети! Точнее, нужно построить правильную цепочку пиров (хостов) для RingSync.

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

статистика –-[*магия*]--> топология сети --[*магия*]--> цепочка пиров

Хотим поделиться своим опытом работы с серверами 1cloud. Мы не хотим никого обвинять, просто хотим выставить проблему на всеобщее обозрение, чтобы у сотрудников 1cloud появилась мотивация для проведения детального анализа данной проблемы.

Началось все с того, что последние месяцы на Windows серверах 1cloud, мы начали замечать аномальную нагрузку, но не придавали этому особого значения, так как Windows сервера в основном использовались для выполнения различных мелких задач типа использование браузера и любых других программ, да и особо не было желания выяснять что там и как.

Но на днях произошла весьма неприятная и оскорбительная ситуация со стороны сотрудников 1cloud, которая подтолкнула нас на публикацию данной статьи. Мы используем сервера 1cloud уже около 1.5-2х лет, правила использования серверов не нарушали. Я был неприятно удивлен, когда зашел в аккаунт и увидел, что все 40 наших серверов заблокированы с пометкой «Сервер заблокирован администратором. Причина блокировки: брутфорс.».

Мир сходит с ума по Xiaomi, скупает Meizu, на чём свет стоит ругает программные оболочки и не перестаёт заказывать смартфоны из Китая. Телефоны стали едва ли не первым продуктом, который смог сбросить с себя проклятие шильдика «Made in China» и превратил его если не в знак качества, то как минимум в знак: «Ого, не хуже флагманов, и дешевле». А ведь буквально в 2006-2007 в России можно было встретить пресловутые Ноклы и Самсоны, которых иногда не хватало даже на один звонок. В этом посте мы немного поностальгируем и окунёмся в историю китайского смартфоностроения, а заодно точно выясним, что выбирали российские пользователи среди китайских смартфонов этим летом. Предупреждаем сразу — топ немного непредсказуем.

Я работаю дата-саентистом в компании CleverDATA. Мы занимаемся проектами в области машинного обучения, и один из наиболее частых запросов на разработку основанных на машинном обучении маркетинговых решений — это разработка рекомендательных моделей.

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

Источник

В начале года мы опубликовали несколько материалов о популярных наборах компонентов для React, Angular и Vue. Сегодня мы представляем вашему вниманию перевод статьи из той же серии, посвящённой React Native. Учитывая непрекращающийся рост популярности React, и то, что мобильные приложения и PWA становятся всё востребованнее, неудивителен тот факт, что React Native привлекает всё большее внимание сообщества разработчиков.



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

Области видимости в JavaScript всегда были непростой темой, особенно в сравнении с более строго организованными языками, такими, как C и Java. В течение многих лет области видимости в JS особенно широко не обсуждались, так как в языке попросту не было средств, которые позволяли бы существенно повлиять на сложившуюся ситуацию. Но в ECMAScript 6 появились некоторые новые возможности, которые позволяют разработчикам лучше контролировать области видимости переменных. Эти возможности в наши дни уже очень хорошо поддерживают браузеры, они вполне доступны для большинства разработчиков. Однако новые ключевые слова для объявления переменных, учитывая ещё и то, что старое ключевое слово var никуда не делось, означают не только новые возможности, но и появление новых вопросов. Когда использовать ключевые слова let и const? Как они себя ведут? В каких ситуациях всё ещё актуально ключевое слово var? Материал, перевод которого мы сегодня публикуем, направлен на исследование проблемы областей видимости переменных в JavaScript.

Длинный пролог

13 сентября 1987 года в жарком бразильском городе Гойяния произошла мелкая кража. Двое мужчин по имени Роберто Алвес и Вагнер Перейра, воспользовавшись отсутствием охраны, пробрались в заброшенный больничный корпус. Разобрав на металлолом странную медицинскую установку, они погрузили детали в тачку и покатили ее домой к Алвесу. Никто не знал, что это начало самого пугающего инцидента с радиоактивными материалами в гражданской сфере.

Да, сотрудники Гойянского Института радиотерапии были в курсе, что при переезде в новое здание установленный в 1977 году громоздкий аппарат лучевой терапии остался на прежнем месте. Но собственник здания открыл имущественный спор с организацией. В дело вступили страховщики, при поддержке полиции запретившие вывозить оставшееся оборудование. На это один из совладельцев Института, Карлос Фигуеиредо Безеррил, только сказал напоследок, что на президенте страховой компании Лисио Боргесе будет лежать ответственность за то, что произойдет с «цезиевой бомбой».

Сисадмин — любимый персонаж айтишных аниме шуток и крутых историй. Кто из нас не помнит заветные 4 слова, обязательные для удачной цитаты на башорге (если кто не помнит — «кот, шредер, админ, х*ясе») и не сопереживал историям с Ithappens, кто не носил шоколадки и пиво, чтобы втихую расширить конторский лимит. Ну, в общем, свой возраст мы уже выдали, поэтому дальше — только о героях сегодняшнего праздника, Дня системного администратора. А точнее — о том, как им тут у нас в 2018 году?

Snob.ru

Привет! Меня зовут Катя, и я работаю тестировщиком мобильных приложений более пяти лет. Последние три года я тружусь в iOS-команде Badoo, и еженедельно мы релизим от трёх до семи новых фич, от трёх до пяти технических тасков и от пяти до 13 багфиксов. Как вы понимаете, приложение меняется с такой скоростью, что поддерживать классическую тестовую документацию (test cases) неэффективно: почти всегда она будет устаревшей.

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

В этом случае визуализация позволяет сэкономить кучу времени, поэтому мы решили попробовать использовать mind maps (или «ментальные карты»), которые так же удобны в использовании, как чек-листы, но более наглядны за счёт визуального формата.

Сегодня мы подробненько разберём созданную мной mind map для тестирования iOS-приложения (далее именуемую «моя прелесть»), а также пройдёмся по ресурсам, которые можно использовать при построении mind map для мобильного приложения, чтобы покрыть максимальное количество важных сценариев.

ДИСКЛЕЙМЕР

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

Здесь приводится опыт, который выдернул меня из состояния «читаю со словарем».



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

Возьмем такой предмет, как английский язык. Там куча понятий: 12 времен глагола, страдательный залог, причастия и т.п. Кто их ввел? Видимо, некие ученые мужи, для которых английский язык был РОДНЫМ. Они жили себе в каком-нибудь Oxford’e или в Cambridg’e и вряд ли знали русский язык.

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

Вспомните, как вы в школе изучали русский язык. Подлежащее, сказуемое, дополнение, определение… и штук 200 правил, из которых куча исключений, которые все благополучно забывают, кроме собственно учителей русского. И которые потом нужны – максимум – при разборках с бюрократическими документами («казнить нельзя помиловать»).

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

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

Статья ориентирована именно на таких.

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

Чтобы понимать, о какой проблеме мы говорим:


400kb скрипта base.js?

Остальное даже не смотрю.
После оптимизации даже без сжатия выигрышь будет в десяки раз и составит:

Мы, айтишники, как никто знаем, насколько часто встречаются стереотипы в мышлении, особенно среди не профессионалов, а любителей от ИТ. Из того, что сразу приходит в голову: если быдлокод, то это PHP; Java только для крупных проектов; Python только для науки; 1С для недопрограммистов. Ясное дело, что это ошибочные суждения, но и появились они не на пустом месте — без массовых прецедентов не обошлось. Всё как в классической мифологии.

Эта мифология коснулась и корпоративного софта. В среде бизнеса сложились довольно однозначные стереотипы: «CRM — программа для продаж», «ERP — космически дорого», «CRM — для всех», «ERP — для межгалактических корпораций». Между тем, ситуация ощутимо изменилась так, что они по сути своей не актуальны, но тем не менее продолжают жить в голове. Как результат, компании отказываются от необходимого уровня автоматизации, путают понятия, получают неэффективные инструменты и т.д.

Пора наводить порядок. Начнём с ERP vs CRM.

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



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

Если же речь идет о том, чтобы исправить погрешности на уже имеющемся сайте, то здесь придется приложить некоторые усилия. Когда я работал в компании Carbon Health, мы как-то раз проверили сайт на доступность при помощи особого расширения в Chrome. Уже на главной странице обнаружилось 28 нарушений, которые необходимо было устранить. На первый взгляд показалось, что это будет очень трудоемкий процесс, но вскоре выяснилось, что внести правки будет не так уж и сложно — нужно только вложить время и разобраться в основах. Нам удалось свести количество нарушений к нулю всего за пару дней.

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

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


Так о чём же надо помнить, чтобы делать работу качественно, и SEO-специалисты были довольны вашей работой?

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

Собеседование — это экзамен

Ведущий — строгий учитель, а кандидат — студент. Классический сеттинг. Обычно проходит так. Спросили откуда ты, что ты, и потом пошло техническое собеседование.

Начинается с простых вопросов на раскачку, примерно таких: